Bug#717076: libjpeg draft resolution
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 [cjwatson@debian.org]
Reply to: