Hi Colin and tech-ctte, I would like to kindly ask if there's anything the rest of us can do to move this forward, so we have a time for a transition before next freeze.
Ondrej On Thu, Mar 20, 2014, at 19:37, Colin Watson wrote: > We've been carrying over an action in TC meetings for some time to draft > a resolution for this, given that the substantive discussion petered out > some time ago. I volunteered to take this on last month and have just > got round to writing something up. > > It is probably clear from this text how I am inclined to vote at this > point; I'm afraid I found it quite difficult to put together a clear > presentation of the libjpeg8/9 case based on the bug and mailing list > threads I worked through. This is only a draft at this point, and I > would invite and welcome constructive corrections and clarifications, > especially from the libjpeg8/9 side of this dispute. I would like to > get this backlogged bug moving again, so I'd suggest that we try to get > this in shape for a vote in about two weeks from now, depending on how > much discussion arises from this. > > I have committed this to the debian-ctte git repository, currently as > "717076_libjpeg/cjwatson_draft.txt". > > > To the Project Secretary: Ian raised the point that he feels that option > A should not require 3:1. The "Provides: libjpeg-dev" here is > essentially a technical device to ensure that packages can declare > Build-Depends: libjpeg-dev and that we get consistent results across the > archive without having to make hundreds of changes to individual > packages. Ian's opinion is that this is a simple case of overlapping > jurisdiction (essentially, maintainership of a package, albeit a virtual > one, under 6.1(2)), and therefore does not require a supermajority. > > Could you please interpret the constitution for us? Does option A > require 3:1, or only a simple majority (perhaps with some trivial > rewording)? Thanks. > > > Whereas: > > 1. There is a dispute between Developers about whether libjpeg8/9 or > libjpeg-turbo should be the default libjpeg implementation in > Debian. The release team does not want to have more than one > libjpeg implementation. > > 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a > suitable replacement, and notes that it does not implement the > full libjpeg8/9 ABI. > > 3. libjpeg8 adds new features to the JPEG image format. These have > however been rejected from the ISO standard, and their > contributions to image quality and compression appear to be widely > disputed. > > 4. libjpeg-turbo is reported to have significantly better performance > than libjpeg, and to be API/ABI-compatible with libjpeg6b. > > 5. libjpeg-turbo is in use by several other distributions (at least > Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, > Blink, Gecko). > > 6. The former organiser of the IJG advised Fedora of his opinion that > libjpeg8 was a "dead end" due to fragmentation. > > 7. The libjpeg-turbo packages in Debian are not yet in a state where > they could be a drop-in replacement for libjpeg8. However, > similar work has been done in Ubuntu and could be adopted. > > 8. In general it does not appear that other Debian packages require > the libjpeg8 API. The sole exception appears to be a "decode from > memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is > implemented by libjpeg-turbo unless configured > --without-mem-srcdst. > > 9. While libjpeg-turbo can be configured with support for much of the > newer interfaces in libjpeg8, it does not support the SmartScale > API. However, images with this extension may have > interoperability problems. Those developers advocating > libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 > APIs there. > > Therefore: > > A (3:1 majority required) > A > A 10. The Technical Committee resolves that libjpeg-turbo should become > A the libjpeg implementation in Debian, using its power under 6.1(2) > A to decide on technical matters of overlapping jurisdiction. > A > A 11. The prospective libjpeg-turbo maintainer should propose an > appropriate > A transition plan for this change, and, after a reasonable period for > A comment, prepare tested packages for upload. > A > A 12. Implementing this change will require removing "Provides: > A libjpeg-dev" from libjpeg8. The libjpeg8 maintainer has made his > A preference clear that libjpeg8 should remain as the default > A libjpeg. Under 6.1(4), we overrule this decision and require that > A this Provides be removed in accordance with the libjpeg-turbo > A transition plan. > > B 10. The Technical Committee resolves that libjpeg8/9 should remain > B the libjpeg implementation in Debian, using its power under 6.1(2) > B to decide on technical matters of overlapping jurisdiction. > > (Option A requires a 3:1 majority.) > > -- > Colin Watson [[email protected]] -- Ondřej Surý <[email protected]> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
