[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <bdale@gag.com> writes:
> > Ian Jackson <ijackson@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

Reply to: