Bug#717076: libjpeg draft resolution
Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A, B, FD. Bdale pgpzCRwbvqqVL.pgp Description: PGP signature
Bug#717076: libjpeg draft resolution
On Thu, Jun 26, 2014 at 07:51:43PM +0100, Ian Jackson wrote: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A FD B. -- Colin Watson [cjwat...@debian.org] signature.asc Description: Digital signature
Bug#717076: libjpeg draft resolution
Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27583.955977.281...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
Ian Jackson writes (Bug#717076: libjpeg draft resolution): Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A, B, FD Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27920.104110.595...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
Ian Jackson ijack...@chiark.greenend.org.uk writes: As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A, B, FD. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ pgpp3UE_HMxGN.pgp Description: PGP signature
Re: Bug#717076: libjpeg draft resolution
On Thu, 26 Jun 2014, Ian Jackson wrote: Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A B FD. -- Don Armstrong http://www.donarmstrong.com I would like to be the air that inhabits you for a moment only. I would like to be that unnoticed that necessary. -- Margaret Atwood Poetry in Motion p140 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626201702.ga30...@rzlab.ucr.edu
Re: Bug#717076: libjpeg draft resolution
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140626 20:54]: Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD Voting A, B, FD. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626223752.gf20...@mails.so.argh.org
Bug#717076: libjpeg draft resolution
Ondřej Surý writes (Bug#717076: libjpeg draft resolution): 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. This was stalled because of an unfortunate interaction with the Project Secretary. I think we should press ahead with our resolution. I have adapted Colin's resolution text. I have: - specified that the transition plan should state timescales - replaced the text saying we were overruling the libjpeg8 maintainer with text explaining that the dropping of the provides is a direct consequence of our decision - explicitly stated that we expect the libjpeg8 maintainer to make the relevant upload in accordance with the plan and said that if it doesn't happen the libjpeg-turbo maintainer should NMU. - consequently option A is now only 1:1 I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. Ian. 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 10. The Technical Committee resolves that libjpeg-turbo should A become the libjpeg implementation in Debian, using its power A under 6.1(2) to decide on technical matters of overlapping A 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. The transition A plan should state the timescales for the relevant changes. A A 12. Implementing the decision in 10 above will require removing A Provides: libjpeg-dev from libjpeg8, since such a virtual A package must be provided by only one real package at a time. A Therefore the Provides should be removed from the libjpeg8 A package - in accordance with the transition plan - A notwithstanding the libjpeg8 maintainer's preference that A libjpeg8 should remain as the default libjpeg. This change A should be made by the libjpeg8 maintainer; if the change is not A made within a reasonable time it should be done in an NMU by the A libjpeg-turbo maintainer. 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. -- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21419.20377.680306.758...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
On Wed, Jun 25, 2014 at 11:39:21PM +0100, Ian Jackson wrote: This was stalled because of an unfortunate interaction with the Project Secretary. I think we should press ahead with our resolution. I have adapted Colin's resolution text. I have: - specified that the transition plan should state timescales - replaced the text saying we were overruling the libjpeg8 maintainer with text explaining that the dropping of the provides is a direct consequence of our decision - explicitly stated that we expect the libjpeg8 maintainer to make the relevant upload in accordance with the plan and said that if it doesn't happen the libjpeg-turbo maintainer should NMU. - consequently option A is now only 1:1 Apologies for dropping the ball on this, and thanks for picking it up. Your changes make sense to me and I'm happy to vote on them. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625224607.gc18...@riva.ucam.org
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
Bug#717076: libjpeg draft resolution
On Fri, Mar 21, 2014 at 06:00:04PM -0700, Russ Allbery wrote: Kurt Roeckx k...@roeckx.be writes: My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. That's one use of virtual packages. However, that's not the primary use of virtual packages for -dev packages. As a general rule, we do not want multiple packages in the archive providing the same -dev package name, because that leads to nondeterministic builds for any package that Build-Depends on the virtual -dev package name, and nondeterministic builds are bad. And I believe the buildds don't even allow it. At least we wants to have that fail but I'm not sure it's still the case. So I keep with my suggestion that you say only 1 package should be providing it instead of saying 1 shouldn't provide it. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322090537.ga3...@roeckx.be
Bug#717076: libjpeg draft resolution
* Kurt Roeckx (k...@roeckx.be) [140322 01:39]: On Fri, Mar 21, 2014 at 11:38:15PM +, Ian Jackson wrote: In general I worry that your interpretation of resolution texts focuses far too much on the exact words used, and far too little on the substance of the underlying issues. In this particular case we have two packages both of which want to claim the libjpeg-dev virtual package name, which for technical reasons ought to be provided by only one of them. Clearly this is a question of overlapping jurisdictions. My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. Well, there are two use-cases of virtual packages. One is multiple packages providing the same service, like mail-transfer-agent. This is typically the case with non-development/library-packages. The other is to provide a development-interface, so that switching from foo(n) to foo(n+1) is easier. In that case, only one of these packages may provide the foo-dev-interface package, because we want to predict which package is used while building with foo-dev. This is typically the case with development/library-packages. Though I'm currently thinking if it wouldn't be better to do a slim real package, because it would also make the autobuilders more happy. But that (using a virtual package this way, or a real) is IMHO setting technical policy, which is also within the domain of the tech ctte (and if you read 6.1.1, it seems that we can there make a technical decision even if developers decided different initially without requiring a 3:1-majority). The difference in my view is that you decide between how a set of related packages should interact with each other or that you prevent 1 package from following the normal rules. I have no problem interpreting the first case as falling under 6.1(2), but I'm not yet sure about the second. If the policy for development packages would be that usually many of them provide the same virtual -dev-package and we would like to kick one out via explicit directive to the maintainer drop that virtual package, I would agree with you. However, the normal rules here are that only one provides it, so I think we are at the first case. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322094955.gb16...@mails.so.argh.org
Bug#717076: libjpeg draft resolution
On Thu, Mar 20, 2014 at 05:37:01PM +, Colin Watson wrote: 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. The text says that you're using your power to decide something under 6.1(4). I can't see how that doesn't require a 3:1 majority. The text is also saying what a specific package should do, and that does sound a lot like overriding a maintainer. So if you really want to prevent using a supermajority, I suggest you write is so that you at least don't mention the other package by name but make it more general. I also suggest you don't mention the name libjpeg-dev directly but instead use words to describe it so that it still applies when it needs to be renamed for whatever reason. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321200014.ga8...@roeckx.be
Bug#717076: libjpeg draft resolution
(resending because of some 8-bit header damage) Kurt Roeckx writes (Bug#717076: libjpeg draft resolution): So if you really want to prevent using a supermajority, I suggest you write is so that you at least don't mention the other package by name but make it more general. Seriously ? I also suggest you don't mention the name libjpeg-dev directly but instead use words to describe it so that it still applies when it needs to be renamed for whatever reason. I think this is contrary to the requirement that the resolution be clear. Given that I think we're not going to be short a 3:1 majority on this, I doubt it really matters in this case, but I'm disappointed. In general I worry that your interpretation of resolution texts focuses far too much on the exact words used, and far too little on the substance of the underlying issues. In this particular case we have two packages both of which want to claim the libjpeg-dev virtual package name, which for technical reasons ought to be provided by only one of them. Clearly this is a question of overlapping jurisdictions. The fact that the resolution to this matter of overlapping jurisdictions will result in specific changes having to be made to one or more packages does not mean that the decision is about overruling the maintainer of the losing package. _Any_ decision about overlapping jurisdictions will necessarily involve directing that certain changes be made to one or more packages which their respective maintainers will not be happy with. I.e. your interpretation as I understand it so far entirely eviscerates the TC's power to rule in case of overlapping jurisdictions. In your view as you have presented it here it appears the TC could say something vague and abstract with 1:1 but if we actually want the losing maintainer to give up the virtual package name we will need to vote again with 3:1. Please reconsider. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21292.52583.383017.107...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140322 00:39]: (resending because of some 8-bit header damage) Kurt Roeckx writes (Bug#717076: libjpeg draft resolution): So if you really want to prevent using a supermajority, I suggest you write is so that you at least don't mention the other package by name but make it more general. Seriously ? I also suggest you don't mention the name libjpeg-dev directly but instead use words to describe it so that it still applies when it needs to be renamed for whatever reason. In this particular case we have two packages both of which want to claim the libjpeg-dev virtual package name, which for technical reasons ought to be provided by only one of them. Clearly this is a question of overlapping jurisdictions. IMHO this is even one of the examples of the constitution for overlapping jurisdiction: | for example, [...] about who should be the maintainer for a package Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321234919.ga16...@mails.so.argh.org
Bug#717076: libjpeg draft resolution
On Fri, Mar 21, 2014 at 11:38:15PM +, Ian Jackson wrote: In general I worry that your interpretation of resolution texts focuses far too much on the exact words used, and far too little on the substance of the underlying issues. In this particular case we have two packages both of which want to claim the libjpeg-dev virtual package name, which for technical reasons ought to be provided by only one of them. Clearly this is a question of overlapping jurisdictions. My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. The difference in my view is that you decide between how a set of related packages should interact with each other or that you prevent 1 package from following the normal rules. I have no problem interpreting the first case as falling under 6.1(2), but I'm not yet sure about the second. The fact that the resolution to this matter of overlapping jurisdictions will result in specific changes having to be made to one or more packages does not mean that the decision is about overruling the maintainer of the losing package. _Any_ decision about overlapping jurisdictions will necessarily involve directing that certain changes be made to one or more packages which their respective maintainers will not be happy with. I.e. your interpretation as I understand it so far entirely eviscerates the TC's power to rule in case of overlapping jurisdictions. In your view as you have presented it here it appears the TC could say something vague and abstract with 1:1 but if we actually want the losing maintainer to give up the virtual package name we will need to vote again with 3:1. I have to guess that as ussual we don't understand each other yet, and probably have a different way of looking at things. And I guess I'm ussually going to try suggesting things so that it's unlikely that people doubt that you do have the power to do something. As ussual this was not an official interpreatation of the constituion yet and I do welcome discussions about such topics, so that we can find a consensus what it says in case of doubt. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322003426.ga26...@roeckx.be
Bug#717076: libjpeg draft resolution
Kurt Roeckx k...@roeckx.be writes: My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. That's one use of virtual packages. However, that's not the primary use of virtual packages for -dev packages. As a general rule, we do not want multiple packages in the archive providing the same -dev package name, because that leads to nondeterministic builds for any package that Build-Depends on the virtual -dev package name, and nondeterministic builds are bad. Rather, for -dev packages, it's more typical to have a virtual package with a single provider at any given point. This is a simpler version of the mechanism used by, e.g., gcc-defaults or boost-defaults, avoiding maintaining as separate source package when there's no need to provide additional supporting files like symlinks. It allows multiple versions of the package to be in the archive at the same time but one of them designated as the default version, using the virtual package Provides, for the purposes of building other packages. This allows packages that actually need a specific version to Build-Depend on that specific version, while moving most of the archive to a new version by moving the Provides and then scheduling binNMUs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ior7hwtn@windlord.stanford.edu
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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140320173701.ga8...@riva.ucam.org
Bug#717076: libjpeg draft resolution
Hi Colin, On Do 20 Mär 2014 18:37:01 CET, Colin Watson wrote: 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. There actually was a first upload to Debian that had those enabled: http://snapshot.debian.org/package/libjpeg-turbo/1.2.90-1/ That version was superceded by another upload removing the drop-in-for-libjpeg8 part while the package was still in NEW. Speaking with my package maintainer hat on: the change can be made easily, once I have a got from the ctte. Mike PS: please note that I will be afk for a week starting tomorrow morning. So if any (more) feedback from my side is required, I can only get back to you after the 29th March. -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpzpdQtrSu5n.pgp Description: Digitale PGP-Signatur
