Re: Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014' (under 22 hours from now)
]] Don Armstrong #topic #733452 init system readiness protocol This was closed by Ian, so why is it on the agenda? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m21tvmc4xz@rahvafeir.err.no
Bug#741573: Two menu systems
I looked through this thread and found that I hadn't proposed anything resembling a concrete resolution. I would like to do that now: Context 1. A dispute about the status of menu systems in Debian, and the contents of policy, has been referred to the Committee. 2. There are currently two menu systems in Debian: the freedesktop.org (.desktop file based) system, and the traditional Debian menu system. 3. These two systems have, in general: different maintainers and proponents; often different users; different intended scopes (in the sense of what subset of packages in Debian should provide menu entries); a different emphasis. 4. The two systems make different choices in response to the need for various technical tradeoffs. The traditional Debian menu is less feature rich, but is easier for a menu consumer. Philosophy 5. Where feasible, there should be room in Debian for competing implementations of similar functionality; especially when they have different but overlapping sets of goals. The contributors to each should be enabled to do their work, so long as the cost for the project as a whole is reasonable. Conclusions 6. Both menu systems should be documented in policy. 7. The documentation for each menu system (specifying file formats, when to include a menu entry, etc.) should follow the views of Debian's experts on, and contributors to, each system. 8. Lack of an entry in one or other menu system, where that system's scope calls for an entry to be provided, is a bug. But it is not a release critical bug. 9. A maintainer should not be criticised for providing a package without doing the work to provide all the applicable menu entries. However, a maintainer who is offered a reasonable patch should accept it. 10. We request that the policy team implement this decision. We leave the specific details of the wording to the policy team. 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/21374.2655.810674.651...@chiark.greenend.org.uk
Re: Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014' (under 22 hours from now)
Don Armstrong writes (Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014' (under 22 hours from now)): The next CTTE meeting is at date -d'Thu May 22 17:00:00 UTC 2014' in #debian-ctte on irc.debian.org (OFTC). The current agenda is in the git repository, and is reproduced below: #startmeeting #topic Who is here? #topic Next Meeting? #topic #717076 Decide between libjpeg-turbo and libjpeg8 et al. #topic #636783 super-majority conflict; #topic #681419 Depends: foo | foo-nonfree #topic #733452 init system readiness protocol #topic #741573 menu systems and mime-support I have added #746715 (init system fallout) to the agenda. 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/21374.3059.194841.496...@chiark.greenend.org.uk
Bug#636783: TC supermajority bug
We discussed this on -project. I have been convinced that my previous approach was wrong. I now think that we should do as follows: * Move the required majority ratio test from A.6(3) to the very end, after A.6(8). * Change the test to =. * The consequence of not meeting the majority ratio would be specified at each place where a majority ratio is mentioned. * Constitutional GRs and foundation document amendments: If the required majority ratio is not met, the consequence would be that the whole GR outcome is FD. * Overriding the TC, and for TC overruling a Developer: If the required majority ratio is not met, the consequence would be that the whole resolution is to be regarded as an advisory statement of opinion, and is not binding. * Explicitly state in A.6(8) that if there is no elector with a casting vote, the default option wins. The results would be: * In a split TC vote with no supermajority requirement, where FD is in the tied set, the elector with the casting vote would be able to choose any of the options, or FD. * Supermajorities are a bare minimum. * Evenly split 1:1 GRs (equal number of votes Y and N) still fail. * A 3:1 GR which obtains votes 300:100 passes where previously it would fail. * We can no longer have a GR which produces in a pathological result where the winning option is eliminated by the supermajority rule leaving a minority view as the prevailing outcome. * In a split TC vote with supermajority requirement, where any of the options beat FD by the supermajority or more: barring pathological situations, there will be one or more options which all beat FD but which are tied or form a Schwartz cycle. Neither FD, nor any non-3:1 options, are likely to be in the Schwartz set. The most likely scenario is a tie about which version of an overruling motion to use. The elector with the casting vote would be able to choose between any of the options in the Schwarz set (ie, probably, any of the tied overruling options) but not be able to choose FD. I haven't yet drafted this up. 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/21374.3886.662499.590...@chiark.greenend.org.uk
Bug#636783: TC casting vote
We have had some discussion about this. No-one seems to have objected to the suggestion that the DPL, rather than the TC chairman, should have a casting vote in TC decisions. I'm therefore intending to roll this up into my TC GR(s). 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/21374.4122.154474.480...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. It is not too late to rectify it. ... A maintainer recently peremptorily removed support for upstart from one of their packages. The Technical Committee thanks Steve Langasek for bringing this matter to our attention. We are pleased that the maintainer has agreed to revert the disputed change. 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. I deliberately don't name or criticise the maintainer. I'm open to suggestions for improvements to the wording, but I think what I have in the final paragraph should be uncontroversial within the TC. Apparently it is controversial within the TC to say even (some) uncontroversial things. Nevertheless, I intend to press for a resolution along these lines. Unless someone comes up with some wording which I consider an improvement I will formally propose the above, and eventually take it to a vote. I'll give a period of at least 72h for opponents to propose amendments. 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/21374.4406.635164.674...@chiark.greenend.org.uk
Bug#636783: TC minimum discussion period
We have discussed having a minimum discussion period for TC resolutions. I still think this is necessary. I think 72h is about right. 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/21374.4519.518604.512...@chiark.greenend.org.uk
Bug#636783: GR giving advice to TC on overruling
I have concluded that it is not going to be feasible for me to find a wording for an advisory GR which will achieve my objectives. I'm therefore dropping it from my personal todo list. I have removed it from the TC git repo. If someone else wants to pick it up, they'd have my support. 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/21374.4876.250713.75...@chiark.greenend.org.uk
Bug#636783: TC casting vote
]] Ian Jackson We have had some discussion about this. No-one seems to have objected to the suggestion that the DPL, rather than the TC chairman, should have a casting vote in TC decisions. I think it's a bad idea. The CTTE is a technical body. The DPL is a political leader. Having political leaders make technical decisions is bad policy. It also means the CTTE is no longer self-contained and half the point of having a chairman disappears. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2ppj5ah41@rahvafeir.err.no
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson wrote: Ian Jackson writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. It is not too late to rectify it. ... A maintainer recently peremptorily removed support for upstart from one of their packages. The Technical Committee thanks Steve Langasek for bringing this matter to our attention. We are pleased that the maintainer has agreed to revert the disputed change. 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. I deliberately don't name or criticise the maintainer. I'm open to suggestions for improvements to the wording, but I think what I have in the final paragraph should be uncontroversial within the TC. Apparently it is controversial within the TC to say even (some) uncontroversial things. From what I can see in the thread, it seems like folks viewed a statement as unnecessary given how rapidly the situation that prompted this got resolved without the need for TC action. It also seems completely understandable, in light of Ubuntu's in-progress migration from upstart to systemd, that a Debian maintainer could see upstart support as unlikely to remain useful. In that regard, I think it would help greatly if the upstart maintainers in Debian (rather than the TC) could post an announcement regarding the long-term plans for upstart in Debian in light of Ubuntu's stated long-term plans. Also, the last paragraph of the statement proposed above does in fact seem controversial; expects maintainers to continue to support is a much stronger statement than expecting maintainers to merge reasonable contributions and not drop such contributions without reason. The latter seems completely reasonable, albeit a somewhat redundant statement of how package maintenance normally works in Debian. The former, expects maintainers to continue to support, assumes such support already exists in all cases, and seems to inherently disregard and disparage packages that specifically make use of the features of one or more init systems and depend on those init systems. Nothing forces a maintainer to add support for any particular init system; it seems reasonable to expect a maintainer to incorporate reasonable changes for another init system, and not intentionally break or drop those changes if they have a reasonable maintenance burden (which holds especially true if those changes have an active maintainer), but the proposed statement as written could easily be used as a hammer against maintainers of packages that support one init system and have received no reasonable contributions to support others. Nevertheless, I intend to press for a resolution along these lines. Unless someone comes up with some wording which I consider an improvement I will formally propose the above, and eventually take it to a vote. I'll give a period of at least 72h for opponents to propose amendments. Not a member of the TC, but nonetheless suggesting the following, in the hopes that a TC member will second it: First, one change that I'd like to see accepted as an amendment to the above, since it doesn't change the stated intent of causing the TC to make a statement in support of multiple init systems: - Dropping the first two paragraphs that make this statement come across as reactionary to a non-specific incident, and instead tweak the third paragraph more along the lines of the statements Ian proposed as part of the previous TC decision on init systems. Posting a reactionary statement in response to an incident that got successfully resolved via normal processes seems like a poor way of encouraging those normal processes. Second, a change I don't expect to see accepted as an amendment, since it tones down the statement in support of multiple init systems to just a reminder about how our existing maintenance processes *already* work for any non-required feature people care about: - Adjusting the last paragraph to be more precise about expectations (and non-expectations) from package maintainers: The TC expects package maintainers to accept and maintain reasonable contributions adding support for multiple init systems, both default and non-default. Packages that already have functional support for multiple init systems should not drop that support without a compelling reason. Finally, in the interests of having an alternative to the current proposal other than FD, to distinguish between we should discuss this further and there's nothing that needs further discussion here, there should be an option on the resulting
Meeting Summary [Re: Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014']
#debian-ctte Meeting Meeting started by dondelelcaro at 16:58:06 UTC. The full logs are available at http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-05-22-16.58.log.html . Meeting summary --- * Who is here? (dondelelcaro, 16:58:27) * Next Meeting? (dondelelcaro, 17:01:35) * AGREED: next meeting thursday june 26th; meeting after that july 31st (dondelelcaro, 17:04:23) * #717076 Decide between libjpeg-turbo and libjpeg8 et al. (dondelelcaro, 17:04:29) * AGREED: preface libjpeg text with using overlapping jurisdictions power rationale (dondelelcaro, 17:07:43) * AGREED: move forward with libjpeg resolution (dondelelcaro, 17:07:55) * ACTION: cjwatson to move forward with libjpeg resolution (dondelelcaro, 17:08:07) * #636783 constitution: super-majority bug (dondelelcaro, 17:08:14) * ACTION: Diziet to work on drafting super-majority resolution (dondelelcaro, 17:10:56) * #636783 constitution: casting vote (dondelelcaro, 17:10:58) * AGREED: take casting vote discussion to e-mail (dondelelcaro, 17:16:42) * #636783 constitution: minimum discussion period (dondelelcaro, 17:16:48) * LINK: http://en.wikipedia.org/wiki/Cloture (rra, 17:22:57) * AGREED: take minimum discussion period to e-mail (dondelelcaro, 17:39:05) * #681419 Depends: foo | foo-nonfree (dondelelcaro, 17:39:11) * ACTION: everyone to read and respond to https://lists.debian.org/debian-ctte/2014/04/msg00060.html if necessary (dondelelcaro, 17:43:46) * ACTION: Diziet to reply to vorlon re #681419 (Diziet, 17:45:43) * AGREED: vote on #681419 once Diziet's point is made (dondelelcaro, 17:46:29) * #733452 init system readiness protocol (dondelelcaro, 17:46:34) * AGREED: close #733452 from agenda (dondelelcaro, 17:46:58) * #741573 menu systems and mime-support (dondelelcaro, 17:47:03) * ACTION: keithp to draft one-menu-system proposal re #741573 (Diziet, 17:59:22) * #746715 init system fallout (dondelelcaro, 17:59:50) * ACTION: Diziet to redraft #746715 (Diziet, 18:23:50) * Additional Business (dondelelcaro, 18:24:29) Meeting ended at 18:27:35 UTC. Action Items * cjwatson to move forward with libjpeg resolution * Diziet to work on drafting super-majority resolution * everyone to read and respond to https://lists.debian.org/debian-ctte/2014/04/msg00060.html if necessary * Diziet to reply to vorlon re #681419 * keithp to draft one-menu-system proposal re #741573 * Diziet to redraft #746715 Action Items, by person --- * Diziet * Diziet to work on drafting super-majority resolution * Diziet to reply to vorlon re #681419 * Diziet to redraft #746715 * keithp * keithp to draft one-menu-system proposal re #741573 * vorlon * Diziet to reply to vorlon re #681419 * **UNASSIGNED** * cjwatson to move forward with libjpeg resolution * everyone to read and respond to https://lists.debian.org/debian-ctte/2014/04/msg00060.html if necessary People Present (lines said) --- * Diziet (165) * rra (105) * bdale (80) * dondelelcaro (77) * vorlon (59) * keithp (28) * Mithrandir (4) * KGB-3 (3) * MeetBot (2) * ansgar (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Don Armstrong http://www.donarmstrong.com There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen -- 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/20140522183437.gt23...@teltox.donarmstrong.com
