Re: GR: Selecting the default init system for Debian

[Russ Allbery]

Guillem Jover  writes:

> But as it stands I think I'm a bit conflicted here, on one hand the
> whole point of the GR is because I don't agree the TC should be
> _deciding_ on this, the project should, but on the other I acknowledge
> there's people that for whatever reason want to defer to the TC.

> So, because that's obviously the will of a part of the project, and
> because an amendment to the GR would be proposed most probably anyway, I
> guess I should just add an option deferring to the TC. Although ideally
> I think the scenario presented above would satisfy everyone, if the GR
> is going to be held anyway.

One way to think of this option is that it's the "further discussion"
option on the GR that you're considering, except more explicit about what
the implications are.

> Honestly, I don't see how that would get us anywhere. We already have
> . Adding something like this to a
> binding ruling affecting Debian, targeted at upstreams, seems a bit
> arrogant to me, because upstreams that have a strong opinion that might
> diverge from our ruling will unlikely change their mind.

Yes, exactly.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppnnff48@windlord.stanford.edu

Re: GR: Selecting the default init system for Debian

[Guillem Jover]

Hi Enrico!

On Sun, 2014-01-19 at 14:56:27 +0100, Enrico Zini wrote:
> On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote:
> > My reasons are quite different to yours: to summarise, it seems to me
> > that the init system decision involves political questions as well as
> > technical ones.
> 
> I would gladly vote an option that says: "technically, we trust what the
> TC says; politically, we are concerned about some of our upstreams'
> choices". A technical endorsement need not also be a political one.

I don't agree these can be detangled, many reasons for such decision
do have basis on non-technical questions (see my reply to Ian). So
the other questions will keep being implicitly there even if it's
supposedly just a “technical endorsement”.

> I would like to keep the technical and political issues as distinct as
> possible, though. I am not interested in spending time evaluating each
> option to form a technical opinion on what the best choice would be, and
> I'm extremely happy that the TC are doing that for me.
>
> I do have personal opinions on some of the upstreams' choices, but I
> believe that they should not get in the way of a technical decision.

To be frank, something I'd actually be very satisfied with, would
be if the TC would have been requested or would decide to issue a
set of non-binding informative documents, or a single or a set of
non-binding recommendations for a default init system, to be used
by people to decide, or to be added as additional explicit option(s)
in the GR deferring to those recommendations.

In fact, I think having a group of individuals (self-elected or not)
on a workgroup doing focused research on difficult issues concerning
project wide direction and presenting their findings and conclusions
for consideration before the project in a non-binding form, would be
excellent; and could help those who are undecided, don't have the time
or energy to expend getting informed, or would like to defer completely
their decision to that workgroup, for example.

But as it stands I think I'm a bit conflicted here, on one hand the
whole point of the GR is because I don't agree the TC should be
_deciding_ on this, the project should, but on the other I acknowledge
there's people that for whatever reason want to defer to the TC.

So, because that's obviously the will of a part of the project, and
because an amendment to the GR would be proposed most probably anyway,
I guess I should just add an option deferring to the TC. Although
ideally I think the scenario presented above would satisfy everyone,
if the GR is going to be held anyway.

> A constructive thing that we may do as a project to address the
> political side of the matter, is to add to our technical decision a list
> of things that we wish our upstreams would do to make all our lives
> easier in the future.

Honestly, I don't see how that would get us anywhere. We already have
. Adding something like this to
a binding ruling affecting Debian, targeted at upstreams, seems a bit
arrogant to me, because upstreams that have a strong opinion that might
diverge from our ruling will unlikely change their mind. I think this
is best left to the one-to-one relationships our maintainers already
have with upstream, at their discretion. We always have the option of
forking, or not packaging upstream software if we so strongly disagree.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140120040409.ga13...@gaara.hadrons.org

Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Guillem Jover writes ("Re: GR: Selecting the default init system for Debian"):
> On Sun, 2014-01-19 at 12:04:17 +, Ian Jackson wrote:
> > My reasons are quite different to yours: to summarise, it seems to me
> > that the init system decision involves political questions as well as
> > technical ones.
> 
> Actually, no, part of my reasons include several of the ones you list,
> as I tried to imply when writting “Such decisions, on issues that are
> as much technical as strategic, political or of a subjective design
> nature,”. I should probably have been more explicit (seems to be a
> common fault of mine :/ ), but didn't want to go into specific details
> for those, I guess that was a mistake. :)

Well of course the more we get into the details of the politics the
more we risk unpleasantness.  :-/.

> For example with strategic, I was thinking about things like:

Thanks for your examples.  Yes, I agree that these are important
questions.

> > However, I think your option (B) needs further reconsideration.  I
> > doubt the project will have the appetite for two GRs on this topic.
> 
> Well, I'd rather not be spending time in the current GR either, I'd
> prefer to be doing something else instead, to be honest. But regarding
> option B, I'd also very strongly prefer if no other GR would appear,
> but I know that some people are eager to get a decision made and be
> done with it (even if it would get postponed now), and will not want
> to wait either, so that was more of a compromise than anything else.

Perhaps there are options that make sense but that don't involve
another GR.  In practice I think few people would vote for a second GR
so at the very least you might consider alternatives.

Ian.


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21212.22453.536649.647...@chiark.greenend.org.uk

Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Holger Levsen writes ("Re: GR: Selecting the default init system for Debian"):
> care to explain why you think so?

Russ has given an answer which I agree with.

But more fundamentally for me: if the project as a whole votes to
overrule the TC on this question, but by a constitutionally
insufficient margin, then I worry that the TC's decision would lack
political legitimacy within the project.

That would risk a lack of wholehearted cooperation from the project as
a whole, erode the authority of the TC, and invite further discussion
of the subject.

> I do think its a useful requirement to avoid $adjective GRs like
> this one (or at least make them harder).

In practice I think that the developers as a whole are mature enough
to take that into consideration in the way they vote.


Bdale asked me in private email why I had changed my mind on this
point since I drafted that part of the constitution.  Here's what I
said:

  I'm not sure whether I would agree that the 2:1 supermajority is
  always wrong.  Russ's scenario seems a good [example of a problem
  with it] to me, so perhaps I'm older and wiser.  To be honest when
  the constitution was being discussed I don't remember anyone
  considering this point.

  But in this particular case the situation seems especially difficult.
  It's certainly clear that the whole thing is very politically charged.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21212.22045.29176.529...@chiark.greenend.org.uk

Re: GR: Selecting the default init system for Debian

[Guillem Jover]

Hi Ian!

On Sun, 2014-01-19 at 12:04:17 +, Ian Jackson wrote:
> Guillem Jover writes ("GR: Selecting the default init system for Debian"):
> > I think that forcing a decision through the TC at this time was very
> > premature and inappropriate, [...]
> 
> Perhaps surprisingly, I am not entirely opposed to the idea of a GR
> for this question.
> 
> My reasons are quite different to yours: to summarise, it seems to me
> that the init system decision involves political questions as well as
> technical ones.

Actually, no, part of my reasons include several of the ones you list,
as I tried to imply when writting “Such decisions, on issues that are
as much technical as strategic, political or of a subjective design
nature,”. I should probably have been more explicit (seems to be a
common fault of mine :/ ), but didn't want to go into specific details
for those, I guess that was a mistake. :)

For example with strategic, I was thinking about things like:

 * Does the project want to align itself with an existing ecosystem
   or distribution?
   - Due to similarities and existing relationships with other
 projects.
   - Or due to perceived number of supporting distributions.
   - Or due to perceived global userbase.
 * Maybe even to try to tip the scale one way or another; either
   to counterweight what might be perceived as having more support
   by the rest of the community so that diversity is preserved, or
   to try to standardize on a global one so that the others can
   wane off, eventually?

For political, several of the ones you've listed, and of a subjective
design nature things like:

 * Being more or less portable, allowing to use the full extent of a
   system, or providing a common baseline for many systems creating
   uniformity.
 * Being more user extensible, or having no knobs and trying to have
   only good defaults.
 * Being tightly coupled or allowing for parts to be easily replaced.
 * Shifting the complexity from system to the users (users here would
   be daemons), or the other way around (implementation and interfaces
   wise).
 * Incremental evolution of existing systems or revolutionary new
   systems.
 * etc.

which in the end are all possible valid design philosophies, with
different tradeoffs, depending on the context, usage, expectations, etc.
Where reasonable people can have opposite opinions or preferences. A
really good characterization of what I mean could be the New Jersey vs
MIT schools of thought, as represented in the well known "The Rise of
Worse is Better" writup.

 

> I do think that the proper process is for the TC to make a decision at
> this stage.  The way I read the constitution and the context is that
> it is the TC's job.  Evidently you disagree.  But there are certainly
> things that some TC members are suggesting which would lead me myself
> to want to propose or sponsor a GR to overturn it.

If the TC was to continue making the decision, I'd want to run the GR
regardless of the outcome, even if I'd agree with it; althought as
I've mentioned before I find the 2:1 majority unfair.

> If we are going to have a GR, we need of course to have all of the
> sensible options on the ballot.  I think your division of the key
> possibilities is sensible.

Thanks.

> However, I think your option (B) needs further reconsideration.  I
> doubt the project will have the appetite for two GRs on this topic.

Well, I'd rather not be spending time in the current GR either, I'd
prefer to be doing something else instead, to be honest. But regarding
option B, I'd also very strongly prefer if no other GR would appear,
but I know that some people are eager to get a decision made and be
done with it (even if it would get postponed now), and will not want
to wait either, so that was more of a compromise than anything else.

> Most people are heartily sick of the subject already, probably.
> (Indeed I'm somewhat worried that people might want to punish the
> proposers and sponsors of a GR for prolonging such a tiresome
> dispute.)

(In a way I guess I accepted that burden when I offered myself as
a sacrificial token.)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119193601.gb4...@gaara.hadrons.org

Re: GR: Selecting the default init system for Debian

[Russ Allbery]

Holger Levsen  writes:
> On Sonntag, 19. Januar 2014, Ian Jackson wrote:

>>> As a TC member, I dislike the supermajority requirement for the project
>>> to overturn a TC decision by GR, particularly in this case. 
>> I agree.  I think that would be quite bad. 

> care to explain why you think so? I do think its a useful requirement to
> avoid $adjective GRs like this one (or at least make them harder).

Supporting a new init system is going to be a group effort by large
portions of the project, and is going to have substantial impact on a lot
of work inside Debian (non-Linux ports, desktop environments, udev
maintenance, convergence or lack thereof with Ubuntu, and so on).  If the
project at large is actually opposed to whatever decision the TC makes,
I think it will be very difficult on a practical level for that decision
to be effective.  (Note that assumes opposition, not "I would have chosen
differently, but this is fine.")

And, more generally, I feel like we should be careful about how much
legitimacy the TC has.  It's an unelected and basically self-selected
group of people, and in that situation, it's quite possible for the TC to
diverge from the goals of the rest of the project and not realize it.
This is something that I think we can manage, particularly given that the
TC members are aware of this and are trying to take it into account, but,
well, one of the great features of Debian for me is that other people
don't tell me what to do.  And of course it's unsurprising that I, as a TC
member, think we can manage that; my opinion isn't the one that matters.

The TC must not become akin to the typical management structure of a
corporation, able to make unaccountable decisions and impose them on the
"workers."  It would destroy one of the major features of Debian as
aproject.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u03kbmh@windlord.stanford.edu

Re: GR: Selecting the default init system for Debian

[Steve Langasek]

On Sun, Jan 19, 2014 at 02:53:26PM +0100, Holger Levsen wrote:
> dropping the useless cc: and not commenting on the thread topic at all so
> far yet...

> On Sonntag, 19. Januar 2014, Ian Jackson wrote:
> > > As a TC member, I dislike the supermajority requirement for the project
> > > to overturn a TC decision by GR, particularly in this case. 
> > I agree.  I think that would be quite bad. 

> care to explain why you think so? I do think its a useful requirement to
> avoid $adjective GRs like this one (or at least make them harder).

Because it doesn't avoid wasting people's time on *holding* the GR; it only
gives the result for all the world to see that the developers prefer one
solution, but the TC prefers another, and the TC's decision would take
precedence.  While there's an argument for having a smaller group spend time
to study the issue more carefully, if the larger group can't overturn the
smaller group's decision with a simple majority, then whatever else that is,
it's antidemocratic.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: GR: Selecting the default init system for Debian

[Gunnar Wolf]

Joerg Jaspert dijo [Sun, Jan 19, 2014 at 11:36:25AM +0100]:
> Where do they decide the global direction for the project? They have a
> technical decision to do. Sure it has a wide impact, but global
> direction is something different than "just" an init thingie.
> 
> 
> Also, seeing how much involvement we have in votes usually, I am far more
> happy to have a small group of people invest a lot of time to get to
> know all the various edges of all the involved systems and making an
> informed decision based on that, giving us long reasonings WHY they
> decided the way they did,
> 
> than having a vote where a few hundred CAN vote, way less than that
> usually DO vote, and even less really inform themself of WHAT they vote
> on. Sure, there may be some who go long ways to get all the details, but
> I could bet their number is SMALL, especially if you look at, eg., how
> deep TC members like Russ went into the issue.
> 
> The quality of the decision will be much better with the CTTE.

I doubt I can state my opinion in a clearer way than what Ganeff has
stated here. I'm completely with him — No good will come from
rehashing the argument in a project-wide fashion once again.


signature.asc
Description: Digital signature

Re: GR: Selecting the default init system for Debian

[Paul Tagliamonte]

On Sun, Jan 19, 2014 at 05:32:46PM +0100, Guillem Jover wrote:
> And yes, when I mentioned "seeking wide deployment", I meant archive
> wide support. Let me try to give an analogy to clarify what I mean.
> Say, the GNU/kFooBar porters might have invested lots of effort into
> their kernel, toolchain and kFooBar-specific utilities, which in
> addition might be in excellent shape; but if the architecture only
> has 10% packages built for that port, and they stop there, then it
> cannot get exposure of its possible features, advantages or different
> ways to do things, and people interested in particular packages might
> not see the point in even giving it a try. Expecting the project at
> large to do the other 90% of the porting seems unrelalistic, even if
> the system has a very solid foundation, because at this point it might
> not show much advantage to the current ones.

Sure. This isn't the init system debate, though. Each init system can
100% boot the system and expose features. You can try to say this is the
other ports (HURD), but I don't think you're seriously asserting
that HURD is 90% of Debian.

> Instead I think the work
> that many porters have done, by sending patches to port packages to
> their systems, have in many cases triggered curiosity to the point of
> people possibly experimenting with those ports, or at least seeing
> value in supporting these even by themselves. There's probably many
> other similar examples, like having excellent cross-building support
> in the toolchain but having no actual cross-buildable package in the
> archive, etc.

I don't grok what this has to do with init systems. Are you saying
they're broken?

> In the upstart case, most of the work could have been reused from
> Ubuntu, w/o interfering with the current init system default. I seem
> to understand reluctance to push native upstart jobs into Debian was
> partially out of respect towards the project. I just think that respect
> was misplaced for something that was optional, and it actually backfired.

You do know upstart can use standard init scripts, yeah?

> Hope that clarifies.

Alas, not for me.

> Thanks,
> Guillem

Much love,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: GR: Selecting the default init system for Debian

[Guillem Jover]

Hi Steve!

On Sat, 2014-01-18 at 19:16:44 -0800, Steve Langasek wrote:
> On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote:
> > Moreover, none of the proponents of alternative init system seem
> > to have expended much energy in seeking wide deployment of their
> > solutions within Debian (or, with the exception of upstart, even
> > updating the policy manual) before this binding ruling was sought.
> 
> […] can I ask how you arrived at the conclusion
> that not much energy has been expended on upstart in Debian?
> 
> I've actually spent quite a lot of time and energy on getting upstart, and
> other base system packages, into a state that users should be able to switch
> from sysvinit to upstart without regressions.  That means getting the
> ifupdown integration in place, making sure lvm and network filesystems work
> at boot, ensuring transparent handling of startpar dependencies on scripts
> that are shadowed by native upstart jobs, etc.

Sorry, that wording was probably unclear. I *do* know you have done
lots of work on upstart in Debian, that's why I also included the point
about the policy update. But here I didn't mention, on purpose, work
done on specific init systems themselves, helpers and immediate
surroundings, but on "wide deployment". I didn't mean to devalue the
work you and other upstart supporters have done (or other init system
alternative supporters for that matter), I'm sorry that might have been
your impression.

> It does *not* mean doing
> very much work on pushing native upstart jobs to maintainers of leaf
> packages; that should be secondary to getting a complete and correct base
> into Debian.  But we certainly are at the point today where such jobs can be
> implemented more widely in packages.
> 
> If you have a different standard for "seeking wide deployment", I'm
> interested to know what it is.

Well, for example, only just very recently it got to a point where
upstart could be installed w/o scary essential removal prompts and
similar (again, work that you did).

And yes, when I mentioned "seeking wide deployment", I meant archive
wide support. Let me try to give an analogy to clarify what I mean.
Say, the GNU/kFooBar porters might have invested lots of effort into
their kernel, toolchain and kFooBar-specific utilities, which in
addition might be in excellent shape; but if the architecture only
has 10% packages built for that port, and they stop there, then it
cannot get exposure of its possible features, advantages or different
ways to do things, and people interested in particular packages might
not see the point in even giving it a try. Expecting the project at
large to do the other 90% of the porting seems unrelalistic, even if
the system has a very solid foundation, because at this point it might
not show much advantage to the current ones. Instead I think the work
that many porters have done, by sending patches to port packages to
their systems, have in many cases triggered curiosity to the point of
people possibly experimenting with those ports, or at least seeing
value in supporting these even by themselves. There's probably many
other similar examples, like having excellent cross-building support
in the toolchain but having no actual cross-buildable package in the
archive, etc.

In the upstart case, most of the work could have been reused from
Ubuntu, w/o interfering with the current init system default. I seem
to understand reluctance to push native upstart jobs into Debian was
partially out of respect towards the project. I just think that respect
was misplaced for something that was optional, and it actually backfired.

Hope that clarifies.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119163246.ga4...@gaara.hadrons.org

Re: GR: Selecting the default init system for Debian

[Holger Levsen]

Hi Guillem,


I think you are missing the following options and have only listed options 
which you consider sensible or which you loath:

h.) support them all equally: systemd, upstart, sysv and openrc and keep sysv 
as the default
i.) support them all equally: systemd, upstart, sysv and openrc and make $foo1 
the default
j) support them all equally: systemd, upstart, sysv and openrc and make $foo2 
the default
k.) support them all equally: systemd, upstart, sysv and openrc and make $foo3 
the default
l.) accept the TC decision, whatever that will be
m.) wait for the TC decision and then revote on this GR
n.) wait for the TC decision and then start a new GR on this topic
o.) my brain hurts, this is difficult, let's go shopping!
p.) further discussion

And, frankly, I'm disappointed by your *lousy* research on the topic (see both 
Tollefs and Steves reply), while at the same time I think you have given an 
*excellent* (bad) example, why voting is or can be bad: uninformed people vote 
on matters they dont fully understand.

Given your lousy research I do assume you havent read the tech-ctte bug in 
question. If you had, I'm don't think you would think the same about the 
topic. (But then, most peoples minds aren't or cannot be changed by new 
information.) 
I do think this bug contains among of the best research of this topic. If you 
as a GR proposer cannot be bothered to inform yourself in the best possible 
way about it, I fear for a rather totally uninformed decision of other voters.


cheers,
Holger, who has come to the conclusion that this init system discussion 
is
way more a bikeshed than what I would have assumed half a year 
ago.
Indeed 99% of our users don't care and the majority of those 
who do 
care want their bikeshed their way or the highway...


signature.asc
Description: This is a digitally signed message part.

Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Enrico Zini writes ("Re: GR: Selecting the default init system for Debian"):
> A constructive thing that we may do as a project to address the
> political side of the matter, is to add to our technical decision a list
> of things that we wish our upstreams would do to make all our lives
> easier in the future.

The main objections to some of the upstreams' behaviours are,
basically, "they don't care what anyone else thinks, and are trying to
impose their will by various means".  If that's the case, further
imprecations aren't likely to make any difference.

So the main political questions for Debian are (a) is this the case ?
(b) does it matter ?  (c) what are we going to do about it ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21211.61095.334496.108...@chiark.greenend.org.uk

Re: GR: Selecting the default init system for Debian

[Enrico Zini]

On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote:

> My reasons are quite different to yours: to summarise, it seems to me
> that the init system decision involves political questions as well as
> technical ones.

I would gladly vote an option that says: "technically, we trust what the
TC says; politically, we are concerned about some of our upstreams'
choices". A technical endorsement need not also be a political one.

I would like to keep the technical and political issues as distinct as
possible, though. I am not interested in spending time evaluating each
option to form a technical opinion on what the best choice would be, and
I'm extremely happy that the TC are doing that for me.

I do have personal opinions on some of the upstreams' choices, but I
believe that they should not get in the way of a technical decision.

A constructive thing that we may do as a project to address the
political side of the matter, is to add to our technical decision a list
of things that we wish our upstreams would do to make all our lives
easier in the future.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: GR: Selecting the default init system for Debian

[Holger Levsen]

Hi,

dropping the useless cc: and not commenting on the thread topic at all so far 
yet...

On Sonntag, 19. Januar 2014, Ian Jackson wrote:
> > As a TC member, I dislike the supermajority requirement for the project
> > to overturn a TC decision by GR, particularly in this case. 
> I agree.  I think that would be quite bad. 

care to explain why you think so? I do think its a useful requirement to avoid 
$adjective GRs like this one (or at least make them harder).


cheers,
Holger





signature.asc
Description: This is a digitally signed message part.

Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Russ Allbery writes ("Re: GR: Selecting the default init system for Debian"):
> Ian Jackson  writes:
> > I do think that the proper process is for the TC to make a decision at
> > this stage.  The way I read the constitution and the context is that it
> > is the TC's job.  Evidently you disagree.  But there are certainly
> > things that some TC members are suggesting which would lead me myself to
> > want to propose or sponsor a GR to overturn it.
> 
> As a TC member, I dislike the supermajority requirement for the project to
> overturn a TC decision by GR, particularly in this case.  I think we would
> all be extremely unhappy if the TC voted one way on the default init
> system and the project then voted a different way by a 60% majority.

I agree.  I think that would be quite bad.  We could explicitly state
in our TC resolution that the TC decision can be vacated by General
Resolution on a simple majority.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21211.51045.916717.913...@chiark.greenend.org.uk

Re: GR: Selecting the default init system for Debian

[Russ Allbery]

I was going to write something longer about this, and I may still
depending on whether I feel like I have a useful way to present the
thoughts that are mingling in my head.  But I wanted to at least briefly
support Ian's point about a GR possibly being a more appropriate
decision-making process if the decision hinges on political rather than
technical grounds.  I don't want to pass the buck, and there's a lot to be
said for a small group of people doing a deep dive into an issue.  But if
this is more of a political question than a technical evaluation, the TC
is in a very awkward place (unelected, basically self-selected, etc.) to
be making political decisions for the project.

Ian Jackson  writes:

> I do think that the proper process is for the TC to make a decision at
> this stage.  The way I read the constitution and the context is that it
> is the TC's job.  Evidently you disagree.  But there are certainly
> things that some TC members are suggesting which would lead me myself to
> want to propose or sponsor a GR to overturn it.

As a TC member, I dislike the supermajority requirement for the project to
overturn a TC decision by GR, particularly in this case.  I think we would
all be extremely unhappy if the TC voted one way on the default init
system and the project then voted a different way by a 60% majority.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4842mel@windlord.stanford.edu

Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Guillem Jover writes ("GR: Selecting the default init system for Debian"):
> I think that forcing a decision through the TC at this time was very
> premature and inappropriate, [...]

Perhaps surprisingly, I am not entirely opposed to the idea of a GR
for this question.

My reasons are quite different to yours: to summarise, it seems to me
that the init system decision involves political questions as well as
technical ones.

Points that have be raised which are essentially political include:

 * What kinds of attitudes are appropriate in an upstream ?
   For example, how much is it reasonable for an upstream for
   a project to require a specific init system ?
 * How much do we as a project care about the non-Linux ports ?
 * How much do we care about desktop vs. non-desktop users ?
 * How much effort are we collectively willing to put into dealing
   with things that upstreams do that we find troublesome
   (implicitly, at the cost of spending time on other things) ?
 * How scared are we of ending up the effective upstream for
   projects of various sizes ? [1]
 * If we are worried about being dictated to by upstreams, which
   upstreams are more scary ?
 * Many of the considerations in your message are matters of
   Debian internal politics.

These are all IMO reasonable questions that one might ask.

I do think that the proper process is for the TC to make a decision at
this stage.  The way I read the constitution and the context is that
it is the TC's job.  Evidently you disagree.  But there are certainly
things that some TC members are suggesting which would lead me myself
to want to propose or sponsor a GR to overturn it.


If we are going to have a GR, we need of course to have all of the
sensible options on the ballot.  I think your division of the key
possibilities is sensible.  However, I think your option (B) needs
further reconsideration.  I doubt the project will have the appetite
for two GRs on this topic.

Most people are heartily sick of the subject already, probably.
(Indeed I'm somewhat worried that people might want to punish the
proposers and sponsors of a GR for prolonging such a tiresome
dispute.)


Thanks for your attention,
Ian.


[1] I don't mention the upstart CLA here because pretty much everyone
agrees that the upstart CLA is ridiculous.  The question is whether it
is in fact a problem for us, which is a mixed technical and political
question.  It boils down to this: how difficult would it be to
maintain it as a fork rather than a downstream (a technical question),
and how likely it is that we will in practice end up with a patch
stack which can't be resolved with upstream changes (a political
question).


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21211.48961.532515.291...@chiark.greenend.org.uk

Re: GR: Selecting the default init system for Debian

[Joerg Jaspert]

On 13461 March 1977, Guillem Jover wrote:

> I think that forcing a decision through the TC at this time was very
> premature and inappropriate

Quite the contrary, it was the right thing to do. This issue will not
get any easier or more clearcut the longer we let it wait and see if
maybe the maintainers will get to a consensus. They won't, this much has
been clear from the beginning, the systems are simply way too different
for that to happen.
So it was the right time (or maybe even a bit late) to ask the TC to
take this decision.

> I feel it's inappropriate for a small group of individuals to forcibly
> decide the global direction for the entire project. Such decisions, on
> issues that are as much technical as strategic, political or of a
> subjective design nature, can have huge implications for what
> contributors or other Debian-based projects might have to work on, or
> stop working on. I feel that such decisions must belong to the project
> at large.

Where do they decide the global direction for the project? They have a
technical decision to do. Sure it has a wide impact, but global
direction is something different than "just" an init thingie.


Also, seeing how much involvement we have in votes usually, I am far more
happy to have a small group of people invest a lot of time to get to
know all the various edges of all the involved systems and making an
informed decision based on that, giving us long reasonings WHY they
decided the way they did,

than having a vote where a few hundred CAN vote, way less than that
usually DO vote, and even less really inform themself of WHAT they vote
on. Sure, there may be some who go long ways to get all the details, but
I could bet their number is SMALL, especially if you look at, eg., how
deep TC members like Russ went into the issue.

The quality of the decision will be much better with the CTTE.

-- 
bye, Joerg
>  I. What would you do if a package has no sane default configuration?
> (There is *no* default configuration that works on most systems!)
   The best thing to do would be to add such a default configuration.
[... ARGS ...]


signature.asc
Description: PGP signature

Re: GR: Selecting the default init system for Debian

[Tollef Fog Heen]

]] Daniel Pocock 

> E.g. if we choose systemd, who will implement all the things that need
> to be changed outside the Gnome related packages?  What will immediately
> fail if not adapted to systemd?

In general, nothing should fail.  sysvinit scripts are first class
citizens in the systemd world and you can have native → sysv → native
dependencies.

There are some bugs, both in systemd and in init script (such as
cycles), but in general this hasn't been a big problem so far.

I believe that the ease of maintenance and the ability to do more with
native systemd units (private /tmp, network namespacing, etc) will make
it interesting for maintainers to move towards native units by
themselves, but there's no flag day involved for a switch-over.

So, I'm not sure what you mean by «all the things that need to be
changed outside the GNOME related packages».  If you have any particular
things in mind, please feel to enumerate them and I'll answer to the
best of my ability.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877g9ws2q0@xoog.err.no

Re: GR: Selecting the default init system for Debian

[Daniel Pocock]

On 19/01/14 03:25, Ben Hutchings wrote:
>
>> In general, I've been quite unhappy with the excessive invocation of
>> the TC recently, with developers seeming to view this as a first,
>> rather than absolute last, resort.
> [...]
>
> Constitutionally, a GR is the last resort in that it can overrule every
> other decision.  A GR can settle a decision finally but does *not*
> create consensus.  So if you honestly think that more time should be
> allowed for a consensus to arise, perhaps you should propose a GR that
> says this issue is not ripe for the TC to decide on and sets some
> minimum delay before it can be brought to the TC again.

It is not about the TC at all (unless they volunteer to do the work to
implement any decision they make)

Ultimately, whatever decision making process is used (GR, TC, etc) there
needs to be some suggestion about who will actually do what and who
presumably won't do anything or what will stop working

E.g. if we choose systemd, who will implement all the things that need
to be changed outside the Gnome related packages?  What will immediately
fail if not adapted to systemd?

If we choose Upstart, it is not quite ready to do everything systemd
would do and we have to trust the developers to follow through on their
commitments to fill those gaps.  I personally believe their intentions
are good but promises are never the same as releases.  If we decide to
give them our trust and for any reason they can't deliver on time, what
would we fall back on, is it enough to say we would just keep sysvinit
for another 2 years, or would we defer the release and wait for them?

Every option - and every fall back option - needs to be explained and
accompanied by some details about who will do what if that option is
chosen, if it hits a snag, etc.  Only then do we have a list of choices
for a GR




-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52db97ff.8070...@pocock.com.au