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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
