Bug#717076: libjpeg draft resolution
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 [cjwatson@debian.org]
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: