init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)
Bdale Garbee bd...@gag.com writes: Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. The Technical Committee does not wish any resolutions it passes about the init system question(s) to stand in the face of any contrary view expressed by a majority of the Developers in a General Resolution. 2. Accordingly, all TC decisions (past and future) related to init systems, which do not specify otherwise, should be read as including the following rider: | This decision is automatically vacated by any contrary | General Resolution which passes by a simple majority. | In that case the General Resolution takes effect and | the whole of this decision is to be taken as withdrawn by the | TC (i.e. as if the TC had explicitly withdrawn it by a | subsequent TC resolution). Please send comments, or formal amendment proposals, by 2014-01-28 17:00 UTC. I will call a vote on some version(s) then. I would strongly prefer you time-bound such a resolution. Burdening all *future* technical committees with an exception to the constitution they must remember and handle seems unkind. Wow, this is amazing. I'm trying to keep track of all the interesting stuff that has happened here so far to preserve it for the future. Is there anything noteworthy that I missed? So far I have (not strictly chronological): * The Debian CTTE is asked to decide about the default init system for Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708) * Off the 8 CTTE members, 2 are starting to dive down into a technical comparison, writing about 98% of all messages sent by ctte members on this topic (FIXME: number is just a guess, need to do proper counting) * One ctte member is appaled by the reaction of the systemd developers and maintainers to his suggestion regarding a daemon startup notification method. He then creates and refers a second issue to the ctte: the design of a daemon readiness protocol (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733452#1501) * A ctte member states that the outright attacks [..] assuming not only bad faith but malicious motives among other people in the free software community that he sees in the messages of another ctte member are deeply disturbing (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2443). * A ctte member devotes a lengthy email to describing how the GNOME Team has a pattern of failing to engage constructively with the rest of the project around crucial integration issues, and that therefore the ctte should not let its decision be influenced by assertions that GNOME upstream is tethering itself to a specific init system. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2638) * The ctte chair asks to try *very* hard to keep [disrespectful sentences] out of the TC discussion. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2468) * The ctte members one by one announce their preferences, resulting in a theoretical (no formal vote was called) 4:4 draw between upstart and systemd. All of 3 Ubuntu (or former Ubuntu) developers in the ctte declare their support for upstart. * A debian developer finds a fairly challeging conflict of interest after a ctte member and Canoncial-employed maintainer of upstart states that decision for systemd would leave Canonical confronting some hard questions about whether to continue investing in upstart development. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810) * An attempt to draft a resolution gets stuck. * A GR is proposed on debian-vote. The option to defer the decision to the ctte seems to get the most vocal support. (XXX) * Some ctte members offer to implement specific functions in their preferred init system in an attempt to sway others to their position. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4031) * The ctte chair calls for vote on the default init system in a ~10 line message without prior discussion of the resolution. The call for votes is not send to the ctte bug, but the ctte mailing list. (xxx) * A ctte member is offended by calling for votes on this resolution without discussing it first, and asks the other members to vote with further discussion because the resolution did not specify that it could be overturned by a GR with simple majority. (XXX) * A ctte resolution to declare that all future ctte decisions relating to the init system will be automatically overruled by GRs with simple majority is proposed. The author states he will call for votes after a discussion period of one day. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4191) * A ctte resolution asserting that sysv init support is mandatory and that no package may depend on a specific init system is proposed. The author states he will call for votes after a discussion
Re: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)
Nikolaus Rath dijo [Mon, Jan 27, 2014 at 06:52:45PM -0800]: (... long list of facts and communication [and nervous?] breakdowns ...) (F'up2 debian-curiosa) This is the first time I feel an off-topic message has reached -curiosa. :-| /me, sick of the perpetual argument... -- To UNSUBSCRIBE, email to debian-curiosa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140128035503.gb49...@gwolf.org
Re: Bug#727708: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)
On Monday, January 27, 2014 18:52:45 Nikolaus Rath wrote: Bdale Garbee bd...@gag.com writes: Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. The Technical Committee does not wish any resolutions it passes about the init system question(s) to stand in the face of any contrary view expressed by a majority of the Developers in a General Resolution. 2. Accordingly, all TC decisions (past and future) related to init systems, which do not specify otherwise, should be read as including the following rider: | This decision is automatically vacated by any contrary | General Resolution which passes by a simple majority. | In that case the General Resolution takes effect and | the whole of this decision is to be taken as withdrawn by the | TC (i.e. as if the TC had explicitly withdrawn it by a | subsequent TC resolution). Please send comments, or formal amendment proposals, by 2014-01-28 17:00 UTC. I will call a vote on some version(s) then. I would strongly prefer you time-bound such a resolution. Burdening all *future* technical committees with an exception to the constitution they must remember and handle seems unkind. Wow, this is amazing. I'm trying to keep track of all the interesting stuff that has happened here so far to preserve it for the future. Is there anything noteworthy that I missed? I'll just mention that the proposal of switching out the default init system in jessie+1 sounds a bit scary, as it will change a basic administration interface in the middle of a Stable support period. Probably the most interesting scenarios with this involve servers running unattended upgrades. [And while it's perhaps not the best time to mention the above, it's been on my mind for a few days, so I'm getting it over with.] As for the TC discussion, it should not be surprising that there is contention, especially if the TC is a representative microcosm of [debian-devel] where likewise there was contention on this issue. Personally I'm more pleased by the work of looking into the code, documentation, considerations of community and licensing, and so on, than not. It's a lot of work to evaluate all of this, and I appreciate the effort each of the TC members has put in. [And likewise all of those outside the TC that were evaluating the choices, regardless of whether doing so loudly or silently.] IMHO the main reason this bug was referred to the TC was to remove ambiguity and so that a choice could be made to allow focusing effort. Regardless of whether it's the right choice, the project needs an answer, so ironically having a choice -- any of the three choices -- may be more important than having the best choice -- especially since what's best is exactly where the most contention lies. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-curiosa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3826515.99kvPm61hh@trelane
Re: Bug#727708: init system discussion - the highlights
]] Chris Knadle I'll just mention that the proposal of switching out the default init system in jessie+1 sounds a bit scary, as it will change a basic administration interface in the middle of a Stable support period. Probably the most interesting scenarios with this involve servers running unattended upgrades. That's not what jessie+1 means. jessie+1 is the release after jessie. If you're running unattended upgrades from one stable release to the next without proper testing first you can expect to run into some trouble. (Most of the basic administration interfaces don't change, though. You can still use service to start/stop services, for instance.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-curiosa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ha8oabvi@xoog.err.no
