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#681419: Alternative dependencies on non-free packages in main: counterargument
Steve Langasek writes (Bug#681419: Alternative dependencies on non-free packages in main: counterargument): Sorry for the delays in writing this up. ... I believe the *spirit* of the policy requirement is twofold: I won't repeat myself too much, but as I have said I think there is a third important underlying principle: The Debian Project Should Not (At least in main) recommend non-free software. I think that includes not mentioning it by name in Depends, Recommends or Suggests. Consider the hypothetical packages gfoo, foo, unfoo I'm going to rename Steve's packages for clarity: foo-gui, nonfreefoo, freefoo (respectively). But if gfoo can't declare 'Depends: unfoo | foo' because foo is a real rather than virtual package, then how can gfoo support those users who choose to install the non-free foo? We know that we don't control the foo package; is the desired outcome here that installing 'foo' must remove 'gfoo'? This problem can be worked around by the use of a suitable indirection metapackage in contrib. main/foo-gui: Depends: freefoo | some-foo contrib/some-foo-nonfree: Provides: some-foo; Depends: nonfreefoo | ... external/nonfreefoo: nothing relevant So I submit that this is not an area where Policy should be enforcing a prohibition on the contents of non-default alternatives. We might recommend the use of virtual packages, but should not micromanage our developers with an outright prohibition. I think the principle that Debian should not recommend nonfree software is important. The situations we are discussing occur only in a handful of cases, and my proposals do not involve unreasonable amounts of work. In particular, I think Steve's example is one where we should certainly not compromise our principles just because some proprietary software distributors are being uncooperative. Our political opponents, with whom we are making a practical compromise, are giving those of us who want to make that compromise a choice between (a) advertising their program or (b) doing some extra work. It is a longstanding tradition in Debian that those who want to work on non-free should bear the costs of complying with our principles. I don't think the minor cost here is worth this compromise - even some would say that the damage to our principles is also fairly minor. 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/21419.21203.232126.860...@chiark.greenend.org.uk
Bug#636783: supermajority bug
The fix to the constitutional supermajority bug has been delayed rather. Sorry about that. I have drafted what I think is an implementation of our conclusions here and in the TC. Opinions welcome. Thanks, Ian. - GENERAL RESOLUTION STARTS - Constitutional Amendment: TC Supermajority Fix Prior to the Clone Proof SSD GR in June 2003, the Technical Committee could overrule a Developer with a supermajority of 3:1. Unfortunately, the definition of supermajorities in the SSD GR has a fencepost error. In the new text a supermajority requirement is met only if the ratio of votes in favour to votes against is strictly greater than the supermajority ratio. In the context of the Technical Committee voting to overrule a developer that means that it takes 4 votes to overcome a single dissenter. And with a maximum committee size of 8, previously two dissenters could be outvoted by all 6 remaining members; now that is no longer possible. This change was unintentional, was contrary to the original intent of the Constitution, and is unhelpful. Additionally, following discussion of the supermajority mechanism within the project, it was realised that certain situations could cause anomalous results: * The existing rules might result in a GR or TC resolution passing which was actually the diametric opposite of the majority view. * The existing rules unintentionally privilege the default option in evenly contested TC votes where no supermajority is required, possibly encouraging tactical voting. Therefore, amend the Debian Constitution as follows: (i) Delete most of A.6(3) (which implemented the supermajority by dropping options at an early stage). Specifically: - Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph A.6(3)(0) before A.6(3)(1). - Remove the rest of A.6(3) entirely, leaving A.6(2) to be followed by A.6(4). (ii) In A.6(8) replace all occurrences of winner with prospective winner. Replace wins in which of those options wins with is the prospective winner. (iii) In A.6(8) add a new sentence at the end: + If there is no elector with a casting vote, the default option + wins. (iv) Add a new section A.6(9) after A.6(8): + 9. 1. If the prospective winner W has no majority requirement, + or defeats the default option D by its majority + requirement, the prospective winner is the actual winner. +2. Otherwise, the motion has failed its supermajority with + the consequences set out alongside the majority + requirement (or, if unspecified, the default option + wins). +3. An option A defeats the default option D by a + majority of N:M if M * V(A,D) is greater than or equal to + N * V(D,A). (v) In * 6.1(4) (Technical Commitee power to overrule a Developer) * 4.1(4) (Developers' use of TC powers by GR) (if another constitutional amendment has not abolished that supermajority requirement) in each case after the N:M majority add + ; failing that, the prospective winning resolution text becomes + a non-binding statement of opinion. (vi) In A.3(2) delete as follows: 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. For the avoidance of any doubt, this change does not affect any votes (whether General Resolutions or votes in the Technical Committee) in progress at the time the change is made. The effect is to fix the fencepost bug, and arrange that failing a supermajority voids the whole decision (or makes it advisory), rather than promoting another option. The fencepost bugfix will also have a (negligible) effect on any General Resolutions requiring supermajorities. And after this change the TC chair can choose a non-default option even if it is tied with a default option. - GENERAL RESOLUTION ENDS - -- 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.25157.72007.339...@chiark.greenend.org.uk
Bug#636783: TC process GRs
We have accumulated the following GR proposals, mostly to do with TC matters: * Fix the supermajority bug. Status: draft text on -vote just sent. * Change the committee size to an odd number to minimise use of the casting vote in highly contested situations. Status: under discussion; text should be simple. Current proposal is to increase to 9. * Set a minimum discussion period for the TC (probably 72h). Under discussion within the TC. * Retirement/rotation of TC members. Proposals being discussed on -project, at a fairly advanced stage of maturity. * Explicitly permit the TC to hold private conversations. These would not include actual votes etc., and are still discouraged. Draft text is ready. * Fix the numbering in appendix A so there is only one A.1. Draft text is ready. I would like to know which if any of these are (a) controversial (b) are related to the others. It would probably be best to lump the uncontroversial ones together into one GR proposal. The others should be separate, unless any of them are entangled. By entangled I mean that a voter's opinion about one of the proposals might depend on whether the other proposal passes. 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/21419.25929.695752.11...@chiark.greenend.org.uk
Bug#746715: Init system fallout draft resolution
Here is the resolution text that I think we agreed at the last meeting. I formally propose this text: The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. As discussed I deleted the contextual and motivational paragraphas and replaced them with the vague intro sentence from IRC and put the bug reference in a footnote. Hopefully this will get consensus. I intend to call for a vote no earlier than after the end of the relevant item in tomorrow's meeting. 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/21419.26600.536212.533...@chiark.greenend.org.uk
Bug#636783: supermajority bug
Russ Allbery writes (Bug#636783: supermajority bug): Ian Jackson ijack...@chiark.greenend.org.uk writes: The fix to the constitutional supermajority bug has been delayed rather. Sorry about that. I have drafted what I think is an implementation of our conclusions here and in the TC. Opinions welcome. I haven't reviewed the wording in detail, but the general discussion and intent looks right to me. Thank you for drafting this! You're welcome. I'd appreciate it if _someone_ would review the wording in detail, and post to say that they'd done so. (That doesn't have to be a TC member, of course.) It would be embarassing to have to fix this _again_ ... 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/21419.26862.520131.304...@chiark.greenend.org.uk
Bug#636783: minimum discussion period
I would like to present an improved proposal for a minimum TC discussionn period, which will allow the committee to move quickly when there is consensus (at least, procedural consensus) within the committee: * Constitution 6.3(1), delete - There is no minimum discussion period; and replace it with a new paragraph inserted into the end of 6.3(1): + There is a minimum discussion period of 5 days. + However, the persion calling a vote may waive the minimum + discussion period; in that case the vote may be cancelled by + any member of the committee, if they do so within 5 days of + the vote being called. 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/21419.28564.8224.671...@chiark.greenend.org.uk
