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

Re: call for votes on default Linux init system for jessie

On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote:
> So... I want to try and simplify this again using essentially the same
> ballot I put forth before, but with all the concerns raised by other
> committee members addressed... except for Ian's demand that we conflate
> the "T vs L" question in the same vote.  I understand this means Ian
> will most likely vote further discussion as his first choice, but I
> sincerely hope the rest of you will not do that and instead vote this
> ballot to a useful conclusion. 

I agree with Ian on this.  At this point, it should be clear to everyone
that, given the stated preferences of each member of the TC, the default
init system for jessie will be systemd.  But I do not think this is the most
important aspect of the problem that needs to be decided.  The question of
how, or if, multiple init systems will coexist in the Debian archive for
jessie is what needs to be decided in order to unblock maintainers and give
them clarity for their own packages.

The only thing that an "up/down" vote on init systems does is placate the
crowds of onlookers who are not part of Debian's decision-making processes,
at the expense of settling the more nuanced questions that need to be
answered for the project.  This should not be our priority.  Our purpose
here is to make sound technical decisions on behalf of the project, not to
preserve the TC's (or Debian's) "reputation" among third parties who have no
legitimate say in the outcome.

I will note for the record here that a number of DDs have at this point
given the TC an ultimatum in private, stating that they will start a GR if
the TC does not call for votes within a specified time limit.  I suspect
that this ultimatum didn't have much effect on Bdale's decision to call for
a vote (since he was already predisposed to having the up/down vote in
question).  Likewise, such an ultimatum doesn't change my view about what
ballot should be voted and when.  And every DD has a constitutional right to
start a GR on this question, at any point.  But it's highly inappropriate to
attempt to pressure the TC into making a quick decision using the *threat*
of a GR.  TC decisions take time precisely because they deal with nuanced
issues that don't get handled any other way.  Rushing to a vote only delays
efforts to reach a consensus in the project, and is counter to the long-term
health of Debian.

> - - - start ballot - - -

> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be

>   D    systemd 
>   U    upstart
>   O    openrc
>   V    sysvinit (no change)
>   F    requires further discussion

> Should the project pass a General Resolution before the release of
> "jessie" asserting a "position statement about issues of the day" on
> init systems, that position replaces the outcome of this vote and is
> adopted by the Technical Committee as its own decision.
> - - - end ballot - - -

I vote F U D O V

I will also point out that splitting this issue into separate ballots in no
way prevents tactical voting, particularly given the small pool of voters
and the resulting likelihood of voting blocks.  If I were less committed to
the integrity of this process, I might have used burying to vote a ballot

  U F O V D

But seeing as I do value the integrity of the process, I will instead
confine myself to observing that I think it's very rude to call a vote while
other members of the committee have made it clear they are still engaged in
discussion to identify ballot options that the whole committee can support.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: