subject:"Bug#727708\: Call for votes on init system resolution"

On Fri, Feb 07, 2014 at 02:41:39PM +, Ian Jackson wrote:
> Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
> > Agreed on both counts.  I understand why Ian (was it?) wanted to have
> > the "multiple init systems for the foreseeable future" text, as a
> > statement of general intent, and I don't disagree with that.  But I
> > would prefer if the specifics ("Therefore, for jessie and later
> > releases:") were marked simply as "Therefore, for jessie:".  That seems
> > to dispose of part of your objection to L.
> 
> I'm afraid that I would be categorically opposed to that change.  That
> would relegate L to a mere transitional provision.  
> 
> I think making the commitment to diversity a long-term intention is
> critically important.

OK.  So I agree that long-term commitment to diversity is important.  I
just don't necessarily agree that the way in which we do so will stay
the same.  For jessie, this amounts to keeping sysvinit support around,
having sufficient non-systemd support available for recent logind and
other new features required by major desktop environments, and not
having a dependency structure such that people end up having to install
a specific init system just in order to keep their systems working.

For later releases, it's not clear to me that we will have the same
constraints.  We might reasonably expect sysvinit support to be less
important, and there are various ways in which diversity criteria could
be met.  It is for example possible that some new feature of systemd
might have a compatible implementation directly in upstart's pid 1
rather than externally.  It's not clear where that sort of thing would
sit relative to L: it wouldn't require *a* specific init system, but it
might exclude some; on the other hand, the presence of two compatible
implementations of an interface should make us substantially more
confident that more are possible, and so I don't think this
automatically implies a lack of diversity.

I think L needs to exclude that sort of thing for jessie as a practical
matter of upgrade handling, but not necessarily for later releases.  But
I don't feel comfortable with us drafting the details of the later parts
of that now, when there are so many unknowns, and reasonable
possibilities of compatible implementations being developed for the
specific details that are currently sticking points.

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207151145.ge2...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 05:39:34PM +0300, Cyril Brulebois wrote:
> Colin Watson  (2014-02-05):
> > The only people who might reasonably be described as vaguely current
> > maintainers of parts of d-i whom I can immediately find on a quick
> > scan of the early parts of this bug are Wouter and myself; Tollef also
> > contributed a good deal in the past, and I may have missed one or two.
> > But I don't think any of these people have been acting as d-i
> > maintainers here.  People like Cyril and Christian, who would be more
> > obvious candidates for such a label, have not commented on this bug.
> 
> I'd like to mention a few things:
>  - TC's opinion (not d-i people's) was queried by Paul.
>  - d-i maintainers were neither asked anything, or put in the loop at
>any point.

Just to clarify things, I wasn't criticising you or anyone else in d-i
for not contributing to this bug, either directly or by implication;
just stating a fact in response to the earlier confusion.

>  - Given the incredible amount of mails on that bug, I think it's quite
>reasonable not to expect us to jump into that train out of the blue,
>especially uninvited.

I think this is indeed entirely appropriate.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207145224.gd2...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

2014-02-07 Thread Cyril Brulebois

Colin Watson  (2014-02-05):
> The only people who might reasonably be described as vaguely current
> maintainers of parts of d-i whom I can immediately find on a quick
> scan of the early parts of this bug are Wouter and myself; Tollef also
> contributed a good deal in the past, and I may have missed one or two.
> But I don't think any of these people have been acting as d-i
> maintainers here.  People like Cyril and Christian, who would be more
> obvious candidates for such a label, have not commented on this bug.

I'd like to mention a few things:
 - TC's opinion (not d-i people's) was queried by Paul.
 - d-i maintainers were neither asked anything, or put in the loop at
   any point.
 - Given the incredible amount of mails on that bug, I think it's quite
   reasonable not to expect us to jump into that train out of the blue,
   especially uninvited. (I've been pointed at this subthread, I could
   have entirely missed it otherwise.)

If you have any question for -boot@, please send a mail there. If you
want some input from either Christian or me, please cc us to ensure we
don't miss that mail.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#727708: Call for votes on init system resolution

Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
> Agreed on both counts.  I understand why Ian (was it?) wanted to have
> the "multiple init systems for the foreseeable future" text, as a
> statement of general intent, and I don't disagree with that.  But I
> would prefer if the specifics ("Therefore, for jessie and later
> releases:") were marked simply as "Therefore, for jessie:".  That seems
> to dispose of part of your objection to L.

I'm afraid that I would be categorically opposed to that change.  That
would relegate L to a mere transitional provision.  

I think making the commitment to diversity a long-term intention is
critically important.

> I get that people want to dispose of this so we never have to consider
> it again, and that we want to provide more certainty of direction; but I
> honestly don't think we should be trying to do that.  As people have
> been saying in other contexts, the probability space collapses quite a
> bit following this decision; with a year of subsequent development the
> proper long-term approach will be much clearer.

My fear is that without the clear statement in favour of diversity,
long-term, those who do not think diversity is important will continue
to create additional technical obstacles.

As a result our freedom of action will be constrained even more then
than it has been now.

Ian.


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

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
> L makes it less likely that Debian will support anything other than the
> default init system in the long run because it undermines the process of
> adding native configuration for non-default init systems.  If we said that
> packages are required to support the default init system and strongly
> encouraged to merge support for those with active communities, I think we
> still wouldn't get 100% archive coverage for the non-default, but I do
> think we'd get coverage for most or all of the packages that people using
> the non-default init system care the most about.  That would probably be
> in the form of native configurations for the init systems that people care
> about, since all the native configurations are simpler and easier to
> maintain than sysvinit scripts.  Packages would then depend on the set of
> init systems that they support.  I think that's about the best solution we
> can hope for in the long run: strong support for the default init system,
> and workable but incomplete support for the other init systems, with clear
> indication in the package dependency structure of what init systems are
> supported.

I do think it's bizarre that we seem to have ended up with coupling
options that don't treat the default init system differently.  This
makes no sense to me, for *either* T or L.  Unfortunately I was severely
backlogged at the point when this was being thrashed out, and I'm not
confident that I follow the reasoning that led to them being drafted in
a way that's entirely agnostic of the default, which is why I haven't
proposed anything else.

My reasoning about the probable effects of L is much more based on
jessie than the long run.  Given that, I don't agree with your reasoning
because I think the injunction to avoid tying higher-level packages to a
specific init system carries more force than the effects of sysvinit
inertia possibly outweighing the activity levels of the various init
system communities; there's still plenty of motivation for those
communities to flesh out native support.  For jessie, I'm not sure I see
any practical difference between L as currently drafted and your
suggestion of "required to support default init system, strongly
encouraged to merge support for other active ones"; these seem likely to
be identical in practice for jessie with sysvinit support still around.
In the long run, I can see your point; but (a) I don't think we should
be attempting to rule on the long run now anyway (see below) and (b)
it's not as if we can't develop new policies to suit changed
circumstances.

Part of my concern with T is that it's so mealy-mouthed.  "Where
feasible", "should", "encouraged", etc.  By contrast, L is a bit
heavy-handed.  It sounds like we may share some common goals between
these, and maybe if we want those to stick properly we need to state
those more explicitly rather than using proxies.  Do we agree, for
instance, that we want it to be possible to run Debian's major desktop
environments with any of the init systems with communities active in
developing support for them?

Your comments about the package dependency structure make sense to me in
the long term.  Where I'm going with my support for L is something like
the zero-one-infinity rule: if a non-init-system package only supports
one system (natively or otherwise, and excluding obvious hacks like
packaging a -dev version of the same system), that may well indicate a
degree of inflexibility, whereas a package that supports more than one
is probably not hard to extend to others.

> Neither T nor L actually imply what I think will happen in practice.  The
> T option gives explicit blessing to adding dependencies on non-default
> init systems, which I think is something that's only appropriate on a
> case-by-case basis for edge packages and cooperating package groups and
> isn't appropriate general advice.  It also doesn't distinguish between
> right now and after the jessie release, which I think is inappropriate.

Agreed on both counts.  I understand why Ian (was it?) wanted to have
the "multiple init systems for the foreseeable future" text, as a
statement of general intent, and I don't disagree with that.  But I
would prefer if the specifics ("Therefore, for jessie and later
releases:") were marked simply as "Therefore, for jessie:".  That seems
to dispose of part of your objection to L.

I get that people want to dispose of this so we never have to consider
it again, and that we want to provide more certainty of direction; but I
honestly don't think we should be trying to do that.  As people have
been saying in other contexts, the probability space collapses quite a
bit following this decision; with a year of subsequent development the
proper long-term approach will be much clearer.

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "u

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> I would really like it that you indicated under which power the
> CTTE is making decisions, and the majority requirements that go
> with that the options, for all your votes.

I have added the following texts to the drafts in git:

+  == introduction (all versions except GR) ==
+
+ We exercise our powers to set technical policy (Constitution 6.1.1)
+ and decide in cases of overlapping jurisdiction (6.1.2):

and

   == version GR (General Resolution) ==

  The Technical Committee requests that the project decide the
  default init system for jessie by means of General Resolution.

+ (This is advice, pursuant to Constitution 6.1.5.)

Does that seem satisfactory to you ?  If you think it's OK I don't
expect any of the TC will object.

Ian.


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

Bug#727708: Call for votes on init system resolution

Sam Hartman writes ("Bug#727708: Call for votes on init system resolution"):
> [some quoted stuff]
>
> I'm a bit confused by this.

To be clear, none of the quoted text is from me.

> I find the votes expressed by TC members entirely consistent with their
> stated verbal positions, and if anything people seem to be using FD
> conservatively, probably indicating a strong desire to be done with this
> process.

Indeed so.  There are options that I consider unacceptable.

Normally I would rank such options below FD and be done with it,
because I felt that failing to make a decision would be worse than
that decision.

But in this case we really desperately need to move on.  Hence the
presence of GR.  If the TC really is deadlocked, then GR ought to win.

So I intend to vote
  [acceptable options], GR, FD, [unacceptable options]
I don't expect many TC members to vote FD above GR.  So when we do the
vote (and don't try to cancel it) I expect a result, even if it's only GR.

Ian.


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

Bug#727708: Call for votes on init system resolution

Nikolaus Rath writes ("Bug#727708: Call for votes on init system resolution"):
> It is not at all clear to me why the CTTE so desperately wants to
> automatically defer to a GR in their resolution. If there is consensus
> to defer to a GR with simple majority among the CTTE, surely it would be
> easy enough to revoke or change the resolution if/when a GR has actually
> happened?

Firstly, it is much easier to get consensus on this in the TC now
while the question of in which direction such a GR might want to
override the TC is far from clear.  Doing it now avoids the danger of
backsliding.

Secondly, I think it's undesirable to have any period of time during
which a GR's decision would not have de jure authority.

Thanks,
Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-07 Thread Sam Hartman

> "Ian" == Ian Jackson  writes:

Ian> Anthony Towns writes ("Re: Bug#727708: Call for votes on init
Ian> system resolution"):
>> It's really pretty terrible to actively use FD to try to block
>> options that aren't your favourite. Honestly, I would have
>> expected the tech ctte to be able to come to a consensus on a set
>> of proposals considered reasonable by all the members, and accept
>> whatever a majority decided. I'd certainly hope that tech ctte
>> members won't tactically change their vote to try to hack the
>> process.

I'm a bit confused by this.  i've always thought ranking options you
consider bad enough that you'd rather have another option to work with
people and discuss the options than see that option pass.  I think by
ranking FD above something you dislike, you should commit to actively
participate in a discussion if FD wins.
However, "I think this option is unacceptable, and so I'd rather discuss
more than decide it," seems like an entirely reasonable use of FD, not
something terrible at all.

I find the votes expressed by TC members entirely consistent with their
stated verbal positions, and if anything people seem to be using FD
conservatively, probably indicating a strong desire to be done with this
process.

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsl61orjary@mit.edu

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 12:04:20AM +0200, Adrian Bunk wrote:
> I am not sure whether Colin is aware that it currently depends on him 
> whether or not DT can win - and whether that might make him consider 
> changing his vote.
> 
> If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
> his ballot, then DT cannot pass FD and is dead.

I have been intentionally trying not to do the Condorcet analysis,
because I consider tactical voting of that kind to be borderline
dishonest.  As it is, I'm far from a voting systems expert and I have to
go to considerable effort to work this sort of thing out, making me
safer against any impulses I might develop to manipulate things.  So I
would actually appreciate it if people did not try to make me aware of
these things.  (I will now try to burn the brain cells involved in
writing this paragraph. :-) )

When deciding my vote, I was trying to bear in mind that decision
paralysis has its own costs to the project: further discussion is not
automatically the safe status quo that it might be in other situations.
Thus, I mainly ranked those options below FD which I considered not to
make enough useful progress, so that we would be very likely to simply
end up back here in a short period of time.  For me, I consider DT (and
for that matter UT) to be a significantly less than ideal compromise;
among other things I don't think it provides enough safeguards against
various kinds of fracturing of the distribution.  But it also doesn't
exclude (what I think of as) better outcomes, and it gets us past this
divisive and exhausting debate and lets us move to a default init which
is better than we have now even if it isn't my preferred one.  So,
taking this into consideration, I placed it barely above FD, and I think
I'd do the same in future votes on similar sets of options.

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207134503.ga2...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

Anthony Towns writes ("Re: Bug#727708: Call for votes on init system 
resolution"):
> It's really pretty terrible to actively use FD to try to block options
> that aren't your favourite. Honestly, I would have expected the tech
> ctte to be able to come to a consensus on a set of proposals
> considered reasonable by all the members, and accept whatever a
> majority decided. I'd certainly hope that tech ctte members won't
> tactically change their vote to try to hack the process.

I intend to vote GR above FD for this reason.

Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-07 Thread Didier 'OdyX' Raboud

Le vendredi, 7 février 2014, 01.08:46 Keith Packard a écrit :
> I think a fair number of us seem to feel that the T/L notion is at
> least as important, if not more important, than the D/U/O/V decision
> as it sets a broader and longer-term precedent for the project than
> choosing which init system should be the default for jessie.

What the technical committee members feel is important to rule upon is 
one thing; what the technical committee can rule upon is defined by our 
constitution. Sometimes there's a mismatch.

> Would it make sense to actually build a ballot that voted this issue
> separately, and do that *before* the default init system for jessie
> vote? We would list all four of the proposed versions (, L, T and
> S).
> 
> (…)
> 
> It seems to me that this issue is clearly a matter of technical policy
> and falls under the ctte purview under section 6.1.1, although I
> believe it has some ambiguity as to whether it is valid because of
> 6.3.5.

Sorry to insist on this point, but I think both L and S fall under 
§6.3.5, specifically under "does not engage in design of new (…) 
policies": for instance, L says "Software outside of an init system's 
implementation may not require a specific init system to be pid 1"; that 
would quite clearly set a new policy.

The latter part of §6.3.5 also applies I think: "The Technical Committee 
restricts itself to choosing from (…) decisions which have been proposed 
and reasonably thoroughly discussed elsewhere", which resonates with 
§6.1.1's parenthesis "the usual maintainer of the relevant (…) 
documentation makes decisions initially" (who would probably be the 
Policy maintainers).

The Tight/Loose/Split-the-init discussion has mostly (if not only) been 
discussed in this bug, by the technical committee members, failing the 
above "elsewhere". Also, the maintainers of the various concerned 
packages (consumers or providers of logind for instance) have also 
clearly stated that their work was stalled by the choice of a default 
init; this policy work hasn't had a chance to happen.

I think it also fails §6.3.6 "Technical Committee makes decisions only 
as last resort", as that specific issue hasn't been brought by the 
Policy maintainers.

Finally, if the matter is of sufficient importance, I'm quite certain 
that it will be brought up to the Technical Committee.

Cheers, OdyX

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

Bug#727708: Call for votes on init system resolution

2014-02-07 Thread Keith Packard

Russ Allbery  writes:

> I consider the L option as currently written to be a commitment to a
> course of action that is technically broken and unsustainable.  I also
> think the effect of L is contrary to its intended goal and will make it
> less likely, not more likely, that Debian will provide working support for
> any init system other than the default in the long run.  (More on that
> below.)

I agree with this, with a slightly greater emphasis on ensuring that
Debian developers continue to have great latitude in choosing how to
package software. I would also have preferred to continue Bdale's ballot
which didn't mention this issue at all.

I think a fair number of us seem to feel that the T/L notion is at
least as important, if not more important, than the D/U/O/V decision as
it sets a broader and longer-term precedent for the project than
choosing which init system should be the default for jessie.

Would it make sense to actually build a ballot that voted this issue
separately, and do that *before* the default init system for jessie
vote? We would list all four of the proposed versions (, L, T and
S).

I don't think guiding the project in this particular area should depend
on which init system was chosen as the default for jessie. I do think
that either you believe that packages should work with any init system,
so that you can separately choose any combination of them, or you
believe that package maintainers should be able to choose a subset of
the available init systems to support, ruling out some combinations.

I readily admit to not really understanding all of the subtleties of our
polling process, but when looking at the votes cast for Ian's proposed
ballot, it looks like we've got a clear set of votes for L vs T already;
each vote places the xL and xT options in the same order for each 'x'.

It seems to me that this issue is clearly a matter of technical policy
and falls under the ctte purview under section 6.1.1, although I believe
it has some ambiguity as to whether it is valid because of 6.3.5. These
options have certainly been proposed and reasonably thoroughly
discussed, although one might not consider the init system bug thread as
separate from the ctte. Of course, it's really a dependency of an issue
which was brought to the ctte, so in a sense, it's a recursive function
call.

-- 
keith.pack...@intel.com

pgphGeaU9EDbb.pgp
Description: PGP signature

Bug#727708: Call for votes on init system resolution

2014-02-07 Thread Andreas Barth

* Russ Allbery (r...@debian.org) [140207 02:09]:
> Anthony Towns  writes:
> 
> > It's really pretty terrible to actively use FD to try to block options
> > that aren't your favourite. Honestly, I would have expected the tech
> > ctte to be able to come to a consensus on a set of proposals considered
> > reasonable by all the members, and accept whatever a majority
> > decided. I'd certainly hope that tech ctte members won't tactically
> > change their vote to try to hack the process.
> 
> > (The obvious counter is for the four members who prefer T to L to vote
> > all the L options below FD in the same way as Andi, Ian and Steve have
> > voted all the T options below FD)
> 
> Exactly.
> 
> I've been trying to refrain from tactical voting of that sort.  I don't
> think that's a slippery slope we should start diving down.
> 
> I also flatly disagree with Adrian over whether we're deadlocked.  I don't
> see any point in discussing it, though.

I agree with you, I don't see any reason why we are deadlocked. If we
want to do yet another round on improving texts this is fine for me,
but should be finished soon. And the following vote should really be
finished, and I expect an outcome from the votes and statements I have
seeing so far. (I don't plan to vote FD again - I even didn't plan it
for this vote, but wanted to give Steve a chance to update the texts,
that is why I changed it for the moment.)


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207091140.gx16...@mails.so.argh.org

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Russ Allbery

Adrian Bunk  writes:

> Leaving tactical aspects aside, IMHO the important point is that there
> is a compromise line that seems reasonable for all members of the TC:

> For the upstart side of the TC, the most important question is T/L.
> For the systemd side of the TC, the most important question is D/U.

I don't agree with this analysis.

I consider the L option as currently written to be a commitment to a
course of action that is technically broken and unsustainable.  I also
think the effect of L is contrary to its intended goal and will make it
less likely, not more likely, that Debian will provide working support for
any init system other than the default in the long run.  (More on that
below.)

L is only "less important" to me because I believe it is unworkable and
unimplementable in the long run, so it doesn't matter *that* much if it
wins, since it will naturally get dropped over time.  Eventually, package
maintainers will realize that the sysvinit scripts everyone has been
keeping around to give lip service to L don't actually work and aren't
actually maintained, and it will end up like other similar Debian features
that are "required" but uninteresting to nearly everyone and therefore
bitrot and are effectively non-functional.

L will cause less short-term damage with systemd as the default init than
with upstart or OpenRC as the default init, so I'm grudgingly willing to
vote DL above FD because the results wouldn't be quite as absurd as the
results of UL would be, but I'm quite far from happy with it.  In
practice, I expect any of the L options to require another round of this
discussion post-jessie to get rid of L again so that we can move forward
without keeping sysvinit scripts.  I certainly hope they will, since the
alternative is to have a decision on the books that maintainers are
supposed to comply with but, in practice, won't, which is an embarassing
and annoying situation to be in.

L makes it less likely that Debian will support anything other than the
default init system in the long run because it undermines the process of
adding native configuration for non-default init systems.  If we said that
packages are required to support the default init system and strongly
encouraged to merge support for those with active communities, I think we
still wouldn't get 100% archive coverage for the non-default, but I do
think we'd get coverage for most or all of the packages that people using
the non-default init system care the most about.  That would probably be
in the form of native configurations for the init systems that people care
about, since all the native configurations are simpler and easier to
maintain than sysvinit scripts.  Packages would then depend on the set of
init systems that they support.  I think that's about the best solution we
can hope for in the long run: strong support for the default init system,
and workable but incomplete support for the other init systems, with clear
indication in the package dependency structure of what init systems are
supported.

L instead requires everyone maintain sysvinit scripts forever, even if
they never use them.  That (a) significantly reduces the incentive to add
the superior native configuration for whatever of systemd, upstart, or
OpenRC are not the default, since it's "handled" by the sysvinit script,
and (b) makes it much less likely that those configurations will actually
be maintained since they're complicated and annoying to try to debug and
harder to write "blind" without running them.  So I believe L is directly
destructive to the stated motives of the people who are in favor of L,
which is one of the reasons why it boggles me that it has so much support.

My preference would be to vote on Bdale's ballot, and I'm unhappy that we
didn't just continue with that vote.  However, I'm almost entirely out of
spoons to keep arguing wording and procedural issues, and I think we're at
the point where this process is starting to cause active damage by
continuing to drag on.  But apparently I'm failing to keep my mouth shut,
so, well, here you go.

Neither T nor L actually imply what I think will happen in practice.  The
T option gives explicit blessing to adding dependencies on non-default
init systems, which I think is something that's only appropriate on a
case-by-case basis for edge packages and cooperating package groups and
isn't appropriate general advice.  It also doesn't distinguish between
right now and after the jessie release, which I think is inappropriate.  I
think there's a huge difference between depending on an init system right
now for the jessie release, which is something I think we should only do
if there's really no technical alternative available at all, and depending
on an init system or set of init systems after jessie, which I think is a
reasonable way of handling the long-term migration path away from
supporting sysvinit scripts.

I tried to raise these issues multiple times and was roundly ignored, so I
gave up

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Adrian Bunk

On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> On 7 February 2014 08:44, Adrian Bunk  wrote:
> > If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
> > then T is dead.
> 
> It's really pretty terrible to actively use FD to try to block options
> that aren't your favourite. Honestly, I would have expected the tech
> ctte to be able to come to a consensus on a set of proposals
> considered reasonable by all the members, and accept whatever a
> majority decided. I'd certainly hope that tech ctte members won't
> tactically change their vote to try to hack the process.
>...

When you are saying "a set of proposals considered reasonable by all the 
members", that basically implies "don't offer the T rider options" since 
these are options that are not considered reasonable by at large part 
(at least 3 members) of the TC.

Leaving tactical aspects aside, IMHO the important point is that 
there is a compromise line that seems reasonable for all members
of the TC:

For the upstart side of the TC, the most important question is T/L.
For the systemd side of the TC, the most important question is D/U.

What we see in the combined vote is actually that DL is an option
that makes both sides win in what they consider their most important
question - and that seems considered reasonable by all TC members.

This is much more possible consensus than what I'd have expected before 
the voting started.

> Cheers,
> aj

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207062927.gg30...@bunk.dyndns.info

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Nikolaus Rath

Russ Allbery  writes:
> Don Armstrong  writes:
>> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
>
>>> So let me expand on that a little.  Image the following options
>>> - A: something that doesn't overrule the ctte (1:1)
>>> - B: something that does overrule the ctte (2:1)
>>> - FD
>
>> In this case, I don't know A could be anything but 2:1, baring riders
>> from the CTTE. If A is technical, it needs the power of the CTTE under
>> §4.1.4 which requires 2:1. [I suppose something could be written which
>> would fall under the DPL's remit.]
>
>> As I understand it, we'd like to make everything be 1:1, and the method
>> we're trying is to write a proposal in such a way that it automatically
>> enshrouds a non-technical statement by the project in the power of the
>> CTTE.
>
>> It may be that we can't actually do that, and should instead just have
>> an agreement between CTTE members to enact a decision which followed a
>> position statement GR under §4.1.5.
>
> I think what we're trying to say looks something like this:
>
> If the project holds a GR vote on the topic of the default init
> system, the winning option of that vote replaces this text in its
> entirety and becomes the decision of the Technical Committee.  The
> winning option of the GR vote for this purpose will be decided
> following the normal rules for deciding the outcome of a General
> Resolution, with the exception that the 2:1 majority normally required
> to overule the Technical Committee will not be taken into account.
>
> I think this works, although it does create the possibility of a rather
> odd situation, and I'm not quite sure how it would work procedurally.
[more complicated stuff snipped]

It is not at all clear to me why the CTTE so desperately wants to
automatically defer to a GR in their resolution. If there is consensus
to defer to a GR with simple majority among the CTTE, surely it would be
easy enough to revoke or change the resolution if/when a GR has actually
happened?


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n4bll3l@vostro.rath.org

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Russ Allbery

Anthony Towns  writes:

> It's really pretty terrible to actively use FD to try to block options
> that aren't your favourite. Honestly, I would have expected the tech
> ctte to be able to come to a consensus on a set of proposals considered
> reasonable by all the members, and accept whatever a majority
> decided. I'd certainly hope that tech ctte members won't tactically
> change their vote to try to hack the process.

> (The obvious counter is for the four members who prefer T to L to vote
> all the L options below FD in the same way as Andi, Ian and Steve have
> voted all the T options below FD)

Exactly.

I've been trying to refrain from tactical voting of that sort.  I don't
think that's a slippery slope we should start diving down.

I also flatly disagree with Adrian over whether we're deadlocked.  I don't
see any point in discussing it, though.

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


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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Anthony Towns

On 7 February 2014 08:44, Adrian Bunk wrote:
> If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
> then T is dead.

It's really pretty terrible to actively use FD to try to block options
that aren't your favourite. Honestly, I would have expected the tech
ctte to be able to come to a consensus on a set of proposals
considered reasonable by all the members, and accept whatever a
majority decided. I'd certainly hope that tech ctte members won't
tactically change their vote to try to hack the process.

(The obvious counter is for the four members who prefer T to L to vote
all the L options below FD in the same way as Andi, Ian and Steve have
voted all the T options below FD)

(Longer term, it seems to me the vote system would be improved by only
allowing voters to cast a vote that ranks the proposed options between
themselves, or to vote for Further Discussion (with no ability to
express preferences amongst the proposals). Quorum would then be
satisfied by having Q votes ranking the options, and a vote would only
be blocked if there was 50% or more of voters voting for FD. A similar
idea to supermajority requirements could be achieved by allowing
proposals to be blocked by 1/N voters voting for FD where N > 2)

Cheers,
aj

--
Anthony Towns

--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cajs_lcvxq2eqa_93so6hg7ng_xrpcjt1u0kojqiri8ejd5t...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Adrian Bunk

On Thu, Feb 06, 2014 at 02:20:51PM -0800, Russ Allbery wrote:
>...
> This is one of the major reasons why I'm voting GR second.  I see Bdale's
> point that we shouldn't abdicate our responsibility to make the best
> decision that we can, and I followed that maxim by voting my preference
> first.  But the reality is that, regardless of whether Condorcet is
> capable of spitting out some technical compromise, we are deadlocked, and
> sufficiently so that we're running into edge case failure modes of the
> standard resolution method.
>...

No, looking at the votes so far you are absolutely not deadlocked since 
you might have a winner that is considered acceptable by all 8 members 
of the TC:

The most problematic option for many TC members is not D or S,
the most problematic option is T.

If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
then T is dead.

But DL might beat FD 8:0, and will likely be the overall winner since it 
is expected to beat UL through the casting vote of the chairman.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206224420.gf30...@bunk.dyndns.info

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Russ Allbery

Adrian Bunk  writes:
> On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:

>> Presuming everyone votes, where you put F only has an impact in either
>> case only if at least three other ctte members will also vote FD above
>> T or DT (given UT is irrelevant); which based on the already expressed
>> preferences and votes, isn't actually going to happen.

> Why not?

> I am not sure whether Colin is aware that it currently depends on him 
> whether or not DT can win - and whether that might make him consider 
> changing his vote.

> If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
> his ballot, then DT cannot pass FD and is dead.

Which is just a concrete way of pointing out that Debian's standard
resolution method fails later-no-harm.

https://en.wikipedia.org/wiki/Later-no-harm_criterion

This is a known weakness in Condorcet, which I suspect we have made worse
with the way that Debian treats FD.

This is one of the major reasons why I'm voting GR second.  I see Bdale's
point that we shouldn't abdicate our responsibility to make the best
decision that we can, and I followed that maxim by voting my preference
first.  But the reality is that, regardless of whether Condorcet is
capable of spitting out some technical compromise, we are deadlocked, and
sufficiently so that we're running into edge case failure modes of the
standard resolution method.

In that situation, the TC recusing itself is not the worst thing that
could happen.

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

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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Adrian Bunk

On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:
> On 7 February 2014 06:20, Ian Jackson  wrote:
> > Don Armstrong writes ("Bug#727708: Call for votes on init system 
> > resolution"):
> >> Given the already stated preferences of the CTTE, and the previous votes
> >> we've already had, openrc and sysvinit are clearly not going to defeat
> >> any option, so their position in your vote is largely irrelevant.
> > If we held the votes separately in the other order, T-vs-L first, and
> > T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
> > first, l don't know whether to rank systemd above GR.
> 
> Based on your initial vote on your own ballot and the above, your
> votes would be:
> 
>   1.  LFT
>   2a. (L wins): UDF
>   2b. (T wins): FUD (*cough*)
> 
> or:
> 
>   1. UD  ("where do I put F?")
>   2. LFT
> 
> Presuming everyone votes, where you put F only has an impact in either
> case only if at least three other ctte members will also vote FD above
> T or DT (given UT is irrelevant); which based on the already expressed
> preferences and votes, isn't actually going to happen.

Why not?

I am not sure whether Colin is aware that it currently depends on him 
whether or not DT can win - and whether that might make him consider 
changing his vote.

If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
his ballot, then DT cannot pass FD and is dead.

> Cheers,
> aj

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206220420.ge30...@bunk.dyndns.info

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Anthony Towns

On 7 February 2014 06:20, Ian Jackson  wrote:
> Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
>> Given the already stated preferences of the CTTE, and the previous votes
>> we've already had, openrc and sysvinit are clearly not going to defeat
>> any option, so their position in your vote is largely irrelevant.
> If we held the votes separately in the other order, T-vs-L first, and
> T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
> first, l don't know whether to rank systemd above GR.

Based on your initial vote on your own ballot and the above, your
votes would be:

  1.  LFT
  2a. (L wins): UDF
  2b. (T wins): FUD (*cough*)

or:

  1. UD  ("where do I put F?")
  2. LFT

Presuming everyone votes, where you put F only has an impact in either
case only if at least three other ctte members will also vote FD above
T or DT (given UT is irrelevant); which based on the already expressed
preferences and votes, isn't actually going to happen.

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJS_LCW7T3jr1=cEWkAy3bevphQETksk2qtX8oRF=wac7vb...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
> Given the already stated preferences of the CTTE, and the previous votes
> we've already had, openrc and sysvinit are clearly not going to defeat
> any option, so their position in your vote is largely irrelevant.

If we held the votes separately in the other order, T-vs-L first, and
T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
first, l don't know whether to rank systemd above GR.

Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Don Armstrong

On Wed, 05 Feb 2014, Ian Jackson wrote:
> Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
> > In fact, if this was your intention all along, it's not clear at all
> > to me why we had to couple these votes.
> 
> You'll notice that my ranking of the init systems differs between the
> T options and the L options.

Sure, but only in regards to whether you vote openrc or sysvinit over
systemd.

Given the already stated preferences of the CTTE, and the previous votes
we've already had, openrc and sysvinit are clearly not going to defeat
any option, so their position in your vote is largely irrelevant.

-- 
Don Armstrong  http://www.donarmstrong.com

Let us chat together a moment, my friend. There are still several
hours until dawn, and I have the whole day to sleep.
 -- Count Orlock in _Nosferatu (1922)_


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206195352.gv24...@rzlab.ucr.edu

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system resolution"):
> On Thu, Feb 06, 2014 at 06:53:56PM +, Ian Jackson wrote:
> > Yes.  What did you think of my proposal earlier ?  If you don't think
> > that has the right effect, please suggest something else.
> 
> Yes, I think that should be fine.

Oh good.

> If the text explicitly says that it is a non-binding position
> statement issued under s4.1.5 of the Constitution, would that suffice ?

For belt and braces, let's do this too.

So for the avoidance of doubt, we would put this into the TC
resolution:

  If the project passes by a General Resolution, a "position statement
  about issues of the day", on the subject of init systems, the views
  expressed in that position statement entirely replace the substance
  of this TC resolution; the TC hereby adopts any such position
  statement as its own decision.

  Such a position statement could, for example, use these words:

 The Project requests (as a position statement under s4.1.5 of the
 Constitution) that the TC reconsider, and requests that the TC
 would instead decide as follows:

This would replace the "GR rider" part in all the substantive TC
ballot options.

So let us suppose that the TC voted for VT (in my existing scheme)
with that rider, a GR to pseudo-override it to exactly the
previously-seen UL proposal would look like this:

   The Project requests (as a position statement under s4.1.5 of the
   Constitution) that the TC reconsider, and requests that the TC
   would instead decide as follows:

   The default init system for Linux architectures in jessie should
   be upstart.

   This decision is limited to selecting a default initsystem for
   jessie.  We expect that Debian will continue to support multiple
   init systems for the foreseeable future; we continue to welcome
   contributions of support for all init systems.

   Therefore, for jessie and later releases:

   Software outside of an init system's implementation may not require
   a specific init system to be pid 1, although degraded operation is
   tolerable.

   Maintainers are encouraged to accept technically sound patches
   to enable improved interoperation with various init systems.

As I understand you, you are saying that such a GR text would require
a 1:1 majority, and would be automatically effective by virtue of the
previous TC decision.

Thanks,
Ian.

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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Don Armstrong

On Thu, 06 Feb 2014, Kurt Roeckx wrote:
> On Thu, Feb 06, 2014 at 10:22:15AM -0800, Don Armstrong wrote:
> > Either of these options will require 2:1, though.
> > 
> > Let me quote §4.1.4:
> > 
> >Together, the Developers may: [...] Make or override any decision
> >authorised by the powers of the Technical Committee, provided they
> >agree with a 2:1 majority.
> > 
> > As you can see, there's no difference between making a decision which
> > requires the CTTE powers (first proposed method), or overriding a
> > decision which requires the CTTE powers (second proposed method).
> 
> It's not clear to me which powers of the the ctte they would be
> overriding.

They would either be using the powers of the CTTE in 6.1.2, 6.1.1, or
6.1.3. 

My point is that there's no difference in the constitution between
developers /making/ a decision that requires CTTE powers and
/overriding/ a decision which requires CTTE powers. [If that was clear
previously, I apologize in advance for becoming more emphatic.]

I suppose there could be some draft texts which did not actually require
the CTTE powers (as a position statement, say), but without language to
the contrary in the CTTE's decision, the majority needed is irrelevant
to whether the CTTE has vacated its decision or not.

-- 
Don Armstrong  http://www.donarmstrong.com

N: Why should I believe that?"
B: Because it's a fact."
N: Fact?"
B: F, A, C, T... fact"
N: So you're saying that I should believe it because it's true. 
   That's your argument?
B: It IS true.
-- "Ploy" http://www.mediacampaign.org/multimedia/Ploy.MPG

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206190849.gu24...@rzlab.ucr.edu

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 06:53:56PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system 
> resolution"):
> > On Thu, Feb 06, 2014 at 06:26:09PM +, Ian Jackson wrote:
> > > If you agree with this reasoning then I'd be grateful if you'd advise
> > > what form of words should be used to achieve the desired effect.  The
> > > desired effect is that:
> > > 
> > >  * A GR option containing a non-binding position statement, requiring
> > >a 1:1 majority, can trigger:
> > > 
> > >  * Provisions in a TC resolution which is conditional on such a GR,
> > > 
> > >  * such that the TC declares in advance that the GR's views are to be
> > >substituted for the TC's.
> > 
> > I guess it should mention that the option in the GR should be a
> > position statement (and should not try to override the CTTE).
> 
> Yes.  What did you think of my proposal earlier ?  If you don't think
> that has the right effect, please suggest something else.

Yes, I think that should be fine.

> > That assumes that the text is actually a position statement.  I'm
> > not sure that I can interprete all texts as position statements.
> > As always, I have to see the text first.
> 
> If the text explicitly says that it is a non-binding position
> statement issued under s4.1.5 of the Constitution, would that suffice ?

Yes.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206185750.ga7...@roeckx.be

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system resolution"):
> On Thu, Feb 06, 2014 at 06:26:09PM +, Ian Jackson wrote:
> > If you agree with this reasoning then I'd be grateful if you'd advise
> > what form of words should be used to achieve the desired effect.  The
> > desired effect is that:
> > 
> >  * A GR option containing a non-binding position statement, requiring
> >a 1:1 majority, can trigger:
> > 
> >  * Provisions in a TC resolution which is conditional on such a GR,
> > 
> >  * such that the TC declares in advance that the GR's views are to be
> >substituted for the TC's.
> 
> I guess it should mention that the option in the GR should be a
> position statement (and should not try to override the CTTE).

Yes.  What did you think of my proposal earlier ?  If you don't think
that has the right effect, please suggest something else.

> That assumes that the text is actually a position statement.  I'm
> not sure that I can interprete all texts as position statements.
> As always, I have to see the text first.

If the text explicitly says that it is a non-binding position
statement issued under s4.1.5 of the Constitution, would that suffice ?

Ian.


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

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 06:26:09PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I think there are basicly 2 ways to go about this:
> > - You revoke your decision during the GR process so that when
> >   the GR is being voted on your decision no longer applies and
> >   the GR isn't trying to override the ctte.  You could for
> >   instance do this at the call for votes point.
> > - The GR will be with 2:1 majority and if it comes to a decision
> >   other than FD, that will be the result.  If the decision of the
> >   GR is FD you could go and re-intreprete it with the 2:1 majority
> >   dropped.
> > 
> > I suggest you go for the first option.
> 
> The Developers have, by way of GR, the ability to express opinions as
> a non-binding "position statement on a matter of the day".  This
> requires a 1:1 majority.

That assumes that the text is actually a position statement.  I'm
not sure that I can interprete all texts as position statements.
As always, I have to see the text first.

> Do you think the Developers lose that ability if their non-binding
> position statement expresses views which are contrary to a decision of
> the TC ?

I don't see how Developers by way of GR can lose any power by a
body inside or outside Debian.

> Do you think the TC can take into account, in its decisionmaking, the
> non-binding views expressed by bodies such as the Developers in
> General Resolution ?  I think, yes.

Yes.

> Do you think the TC can make its decisions conditional on future
> events ?  I think, yes.  Is that in any way limited to the kinds of
> future events ?  I think not.

I already said they can.  But I also said it will depend on the
wording.

> If you agree with this reasoning then I'd be grateful if you'd advise
> what form of words should be used to achieve the desired effect.  The
> desired effect is that:
> 
>  * A GR option containing a non-binding position statement, requiring
>a 1:1 majority, can trigger:
> 
>  * Provisions in a TC resolution which is conditional on such a GR,
> 
>  * such that the TC declares in advance that the GR's views are to be
>substituted for the TC's.

I guess it should mention that the option in the GR should be a
position statement (and should not try to override the CTTE).


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206184954.gb7...@roeckx.be

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 10:22:15AM -0800, Don Armstrong wrote:
> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
> > I think there are basicly 2 ways to go about this:
> > - You revoke your decision during the GR process so that when
> >   the GR is being voted on your decision no longer applies and
> >   the GR isn't trying to override the ctte.  You could for
> >   instance do this at the call for votes point.
> > - The GR will be with 2:1 majority and if it comes to a decision
> >   other than FD, that will be the result.  If the decision of the
> >   GR is FD you could go and re-intreprete it with the 2:1 majority
> >   dropped.
> 
> Either of these options will require 2:1, though.
> 
> Let me quote §4.1.4:
> 
>Together, the Developers may: [...] Make or override any decision
>authorised by the powers of the Technical Committee, provided they
>agree with a 2:1 majority.
> 
> As you can see, there's no difference between making a decision which
> requires the CTTE powers (first proposed method), or overriding a
> decision which requires the CTTE powers (second proposed method).

It's not clear to me which powers of the the ctte they would be
overriding.  I can't say anything about that until someone
actually makes a draft text for that GR.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206183701.ga7...@roeckx.be

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> I think there are basicly 2 ways to go about this:
> - You revoke your decision during the GR process so that when
>   the GR is being voted on your decision no longer applies and
>   the GR isn't trying to override the ctte.  You could for
>   instance do this at the call for votes point.
> - The GR will be with 2:1 majority and if it comes to a decision
>   other than FD, that will be the result.  If the decision of the
>   GR is FD you could go and re-intreprete it with the 2:1 majority
>   dropped.
> 
> I suggest you go for the first option.

The Developers have, by way of GR, the ability to express opinions as
a non-binding "position statement on a matter of the day".  This
requires a 1:1 majority.

Do you think the Developers lose that ability if their non-binding
position statement expresses views which are contrary to a decision of
the TC ?  Or do they lose that ability if their non-binding position
statement express views which are contrary to the decisions of an
individual Developer ?  Or if their non-binding position statement
expresses views which are contrary to the decisions of a body outside
Debian over which the Developers obviously have no authority ?  Surely
not, to all three of these.

Do you think the TC can take into account, in its decisionmaking, the
non-binding views expressed by bodies such as the Developers in
General Resolution ?  I think, yes.

Do you think the TC can make its decisions conditional on future
events ?  I think, yes.  Is that in any way limited to the kinds of
future events ?  I think not.

So, then I think that the TC has the power to make its decisions
dependent on the expression (or lack of expression) of views in a
non-binding position statement General Resolution.

If you agree with this reasoning then I'd be grateful if you'd advise
what form of words should be used to achieve the desired effect.  The
desired effect is that:

 * A GR option containing a non-binding position statement, requiring
   a 1:1 majority, can trigger:

 * Provisions in a TC resolution which is conditional on such a GR,

 * such that the TC declares in advance that the GR's views are to be
   substituted for the TC's.

Thanks,
Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Don Armstrong

On Thu, 06 Feb 2014, Kurt Roeckx wrote:
> I think there are basicly 2 ways to go about this:
> - You revoke your decision during the GR process so that when
>   the GR is being voted on your decision no longer applies and
>   the GR isn't trying to override the ctte.  You could for
>   instance do this at the call for votes point.
> - The GR will be with 2:1 majority and if it comes to a decision
>   other than FD, that will be the result.  If the decision of the
>   GR is FD you could go and re-intreprete it with the 2:1 majority
>   dropped.

Either of these options will require 2:1, though.

Let me quote §4.1.4:

   Together, the Developers may: [...] Make or override any decision
   authorised by the powers of the Technical Committee, provided they
   agree with a 2:1 majority.

As you can see, there's no difference between making a decision which
requires the CTTE powers (first proposed method), or overriding a
decision which requires the CTTE powers (second proposed method).

We want to draft language which avoids this, which is what the paragraph
in question (and Ian's paragraph in [1]) attempt to do.

1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5684
-- 
Don Armstrong  http://www.donarmstrong.com

A kiss was mysterious and powerful, fragile and invincible. Like any
spark, a kiss might fizzle into nothing or consume an entire forest.
[...] A kiss could change the entire world.
  -- Scott Westerfeld _The Killing of Worlds_ p336

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206182215.gr24...@rzlab.ucr.edu

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 10:58:06PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > Please do not assume I have time to read everything.  I don't.  I
> > actually think I gave advice about this before which you seem to
> > have ignored.
> 
> I'm sorry if I also missed a mail.
> 
> > > Anyway, I think as regards T vs L we are chiefly exercising our power
> > > to set technical policy.  As regards the default init system we are
> > > making a decision which has been requested of us by the people
> > > normally responsible (which would be the d-i maintainersI think).
> > 
> > I would like to point out that this was requested by Paul
> > Tagliamonte, who as far as I know is not in the d-i team.  I
> > didn't see anybody from the d-i team request that you make a
> > decision for them, but I might have missed that.
> 
> I assume you would like us to cancel the current vote and address
> these points.

I have no problem with the vote being held.  However I might feel
the need partially revoke the decision at some point.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206180453.gb5...@roeckx.be

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 10:31:24PM -0800, Russ Allbery wrote:
> Don Armstrong  writes:
> > On Thu, 06 Feb 2014, Kurt Roeckx wrote:
> 
> >> So let me expand on that a little.  Image the following options
> >> - A: something that doesn't overrule the ctte (1:1)
> >> - B: something that does overrule the ctte (2:1)
> >> - FD
> 
> > In this case, I don't know A could be anything but 2:1, baring riders
> > from the CTTE. If A is technical, it needs the power of the CTTE under
> > §4.1.4 which requires 2:1. [I suppose something could be written which
> > would fall under the DPL's remit.]
> 
> > As I understand it, we'd like to make everything be 1:1, and the method
> > we're trying is to write a proposal in such a way that it automatically
> > enshrouds a non-technical statement by the project in the power of the
> > CTTE.
> 
> > It may be that we can't actually do that, and should instead just have
> > an agreement between CTTE members to enact a decision which followed a
> > position statement GR under §4.1.5.
> 
> I think what we're trying to say looks something like this:
> 
> If the project holds a GR vote on the topic of the default init
> system, the winning option of that vote replaces this text in its
> entirety and becomes the decision of the Technical Committee.  The
> winning option of the GR vote for this purpose will be decided
> following the normal rules for deciding the outcome of a General
> Resolution, with the exception that the 2:1 majority normally required
> to overule the Technical Committee will not be taken into account.

I think there are basicly 2 ways to go about this:
- You revoke your decision during the GR process so that when
  the GR is being voted on your decision no longer applies and
  the GR isn't trying to override the ctte.  You could for
  instance do this at the call for votes point.
- The GR will be with 2:1 majority and if it comes to a decision
  other than FD, that will be the result.  If the decision of the
  GR is FD you could go and re-intreprete it with the 2:1 majority
  dropped.

I suggest you go for the first option.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206175902.ga5...@roeckx.be

Re: Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Keith Packard

Colin Watson  writes:

> I think I signed my votes when I started on the TC, but then noticed
> that nobody else was doing so and stopped bothering.  I can go back to
> signing them in future, though, since it sounds like it would make some
> people more comfortable.

I just sign all of my email, although I'm using a key that hasn't yet
made it into the debian keyring.

-- 
keith.pack...@intel.com


pgpKzlZxXinF4.pgp
Description: PGP signature

Bug#727708: Call for votes on init system resolution

Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
> Changing my vote to:
> 
>   1.  FD   further discussion

With this and Colin's change of vote, 4 TC members have ranked FD
first.  The outcome is no longer in doubt: FD wins.

Ian.


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

Re: Bug#727708: Call for votes on init system resolution

[bug CC removed]

On Thu, Feb 06, 2014 at 12:46:32AM +0100, Kurt Roeckx wrote:
> On Thu, Feb 06, 2014 at 12:40:22AM +0100, Philipp Kern wrote:
> > I'd prefer if CTTE members would actually sign their votes. (But I
> > guess it's up to the secretary.)
> 
> I've actually asked that they do that before, but it's not really
> a requirement.

I think I signed my votes when I started on the TC, but then noticed
that nobody else was doing so and stopped bothering.  I can go back to
signing them in future, though, since it sounds like it would make some
people more comfortable.

(There are few enough of us that impersonation attempts would be pretty
easy to spot from Received headers and such if anyone suspected
something, anyway.)

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206160629.gb13...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
> I hope we only have to go round this business once more!

Quite!

Thanks,
Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Steve Langasek

On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote:
> On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote:
> > Ian Jackson writes ("Bug#727708: package to change init systems"):
> > > I now intend to do the CFV at 16:30 UTC on Wednesday.

> > I hereby call for votes on my previously proposed resolution and
> > amendments.  All the options require a simple majority.

> > The list of options, and full resolution text, are reproduced below.

Changing my vote to:

  1.  FD   further discussion
  2.  UL   upstart default in jessie, requiring specific init NOT allowed
  3.  DL   systemd default in jessie, requiring specific init NOT allowed
  4.  OL   openrc default in jessie, requiring specific init NOT allowed
  5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
  6.  UT   upstart default in jessie, requiring specific init is allowed
  7.  DT   systemd default in jessie, requiring specific init is allowed
  8.  OT   openrc default in jessie, requiring specific init is allowed
  8.  VT   sysvinit default in jessie, requiring specific init is allowed
  9.  GR   project should decide via GR

To rank FD first and allow a bit more time for drafting something we can all
agree on.  Thanks to Ian for being agreeable to this.

-- 
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

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 10:32:10PM +, Colin Watson wrote:
> On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote:
> > I hereby call for votes on my previously proposed resolution and
> > amendments.  All the options require a simple majority.
> 
> I vote:

In response to the uncertainty about the constitutional validity of this
vote, and since Steve still has redrafting he wants to see on the
ballot, I'm changing my vote as follows:

  1. FD   further discussion
  2. UL   upstart default in jessie, requiring specific init NOT allowed
  3. DL   systemd default in jessie, requiring specific init NOT allowed
  4. OL   openrc default in jessie, requiring specific init NOT allowed
  5. UT   upstart default in jessie, requiring specific init is allowed
  6. DT   systemd default in jessie, requiring specific init is allowed
  7. GR   project should decide via GR
  8. OT   openrc default in jessie, requiring specific init is allowed
  9. VL   sysvinit default in jessie, requiring specific init NOT allowed
 10. VT   sysvinit default in jessie, requiring specific init is allowed

I hope we only have to go round this business once more!

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206155603.ga13...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

Ian Jackson writes ("Bug#727708: Call for votes on init system resolution"):
> Steve Langasek writes ("Bug#727708: Call for votes on init system 
> resolution"):
> > I vote:
> > 
> >  1.  UL   upstart default in jessie, requiring specific init NOT allowed
> >  2.  DL   systemd default in jessie, requiring specific init NOT allowed
> >  3.  FD   further discussion
> 
> If you are serious about wanting to discuss the drafting further, you
> should vote FD first

Also, if you are serious about wanting to do additional drafting work,
I think you need to manage a lower latency and greater bandwidth of
interaction with the process.

Ian.


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

Bug#727708: Call for votes on init system resolution

Russ Allbery writes ("Bug#727708: Call for votes on init system resolution"):
> I think what we're trying to say looks something like this:
...
> The result of that GR is A.  However, the choice picked by the above
> algorithm is B.  So B becomes the TC decision, despite the fact that A is
> the result of the GR, and A, despite winning, now constitutes a TC
> override and fails to go into effect.  Unless you think of A happening
> "before" the TC decision changes, at which point the TC can no longer
> override it?

This is the wrong way to look at it.

The right way to look at it is this: exercising this "override" this
must be achieved by using options which constitutionally require only
a 1:1 majority.

Helpfully, 4.1.5 permits this.

How about this:

  If the project passes by a General Resolution, a "position statement
  about issues of the day", on the subject of init systems, the views
  expressed in that position statement entirely replace the substance
  of this TC resolution; the TC hereby adopts any such position
  statement as its own decision.

  Such a position statement could, for example, use these words:

 The Project requests that the TC reconsider, and requests that
 the TC would instead decide as follows:

Ian.


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

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 07:42:41AM +0100, Lucas Nussbaum wrote:
> On 05/02/14 at 22:41 +, Thorsten Glaser wrote:
> > I think it is not up to the d-i people to decide on the init system
> > anyway – especially as not d-i but debootstrap is the canonical way
> > to install Debian… and debootstrap goes by whatever ftp-masters put
> > into the override files, and whatever package dependencies and meta
> > information (such as Essential: yes) there are.

The latter's true, yes, but this is a distinction without a difference.
debootstrap has been maintained by the d-i team since 1.0.0 in 2007.

> > So, “jurisdiction overlaps” seems to fit quite well.
> 
> As far as I remember, I don't think that any of the d-i maintainers,
> debootstrap maintainers, ftpmasters, or sysvinit maintainers have
> claimed that it was their sole jurisdiction to decide on the default
> init system. So I agree that there's jurisdiction overlap.

Right.  A simple thought experiment to get a first approximation of
jurisdiction in Debian is to look at who might be able to put a given
change into effect as part of their ordinary work, changing only the
things they're generally agreed to "own".  Using that we get at least
this result:

 * ftpmaster could change Priority fields to cause a different init
   system to be the default

 * the debootstrap maintainers / d-i team could decide to act at
   variance with the Priority fields and install a different init
   system; there's plenty of precedent for not going just by Priority,
   and we might reasonably want it to have options to do so in this case
   anyway

 * the sysvinit maintainers could decide to throw in the towel and make
   sysvinit a transitional package for some other init system
   [hey, I didn't say all these options were realistic]

 * any boot loader maintainer could decide to tweak their default
   configuration to pass init=something (indeed for a while I thought
   that that might well end up being the implementation mechanism for
   the result of this vote, although I've since been cluebatted
   otherwise)

 * the maintainers of a sufficiently widely-used package could cause it
   to depend on a given init system

So, yes.  I would be interested in whether the Secretary agrees whether
this is jurisdictional overlap.  If the answer is no, then it would be
very helpful to have examples of what would be so that we can act
accordingly in the future.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206110944.gc15...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 10:43:25PM +, Thorsten Glaser wrote:
> Colin Watson dixit:
> >Various developers certainly continue to work enthusiastically on their
> >preferred approaches, but that's not really the same as "efforts to
> >resolve [the issue] via consensus".
> 
> But is not diversity some sort of consensus too? Let’s just support
> all of them…

It is not clear to me that there is even consensus for diversity!

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206105347.gb15...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

2014-02-06 Thread Rick Yorgason

This is silly. It's pretty clear that everybody made up their minds a 
long time ago, and no matter how the resolution is worded, it will come 
down systemd > upstart 5:4. The only question is on how to guide 
maintainers once the init system is changed.


-Rick-


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f36119.6030...@firefang.com

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Anthony Towns

On 6 February 2014 16:27, Anthony Towns  wrote:
> Rankings between remaning actual outcomes is:
>   4x  UL > DL > UT > DT  (steve, colin, ian, andi)
>   2x  DT > DL > UT > UL  (russ, don)

Ah! I thought there was something to add here

The above votes divide neatly into upstart v systemd camps. Given
Bdale and Keith have expressed a preference for systemd previously,
presumably they fall onto the systemd side; so will vote presumably
vote either DT or DL above the other options, and will vote DL > UL,
and DT > UT.

In that case,

  DL > UT6:2, 7:1 or 8:0

  DL >= DT  6:2, 5:3 or 4:4
  UL >= UT  6:2, 5:3 or 4:4
  UL >= DT  6:2, 5:3 or 4:4

  DT = UT  4:4
  DL = UL  4:4

UT would thus have no chance of being in the Schwartz set (it doesn't
beat anything, and is beaten by DL).

Possible outcomes are then:

  DL >= DT  6:2, 5:3 or 4:4
  UL >= DT  6:2, 5:3 or 4:4
  DL = UL4:4

ie:
 - if either Bdale or Keith vote DT below UL or DL, DT loses, and the
result is determined by Bdale's casting vote between UL and DL
 - otherwise, the result is determined by Bdale's casting vote amongst
UL, DL and DT

Also, Russ correctly points out:
> >   DL > GR 6:0
> For whatever it's worth, I think this line is wrong.  I voted GR above DL.

Hopefully there wasn't much else wrong with the analysis. (Having 10
options on a vote that's supposed to have its results tallied by hand
seems nuts to me...)

Cheers,
aj

-- 
Anthony Towns 

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajs_lcvgqenurnnuzffvwfw29wvadt3su1wveabffnwc-l2...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Lucas Nussbaum

On 05/02/14 at 22:41 +, Thorsten Glaser wrote:
> Colin Watson dixit:
> 
> >("Decide any technical matter where Developers' jurisdictions overlap").
> 
> I think it is not up to the d-i people to decide on the init system
> anyway – especially as not d-i but debootstrap is the canonical way
> to install Debian… and debootstrap goes by whatever ftp-masters put
> into the override files, and whatever package dependencies and meta
> information (such as Essential: yes) there are.
> 
> So, “jurisdiction overlaps” seems to fit quite well.

As far as I remember, I don't think that any of the d-i maintainers,
debootstrap maintainers, ftpmasters, or sysvinit maintainers have
claimed that it was their sole jurisdiction to decide on the default
init system. So I agree that there's jurisdiction overlap.

Also, given that:

  The Project Leader may:
4. Make any decision for whom noone else has responsibility.

and:

  The Project Leader may:
1. Appoint Delegates or delegate decisions to the Technical
Committee.

  The Leader may define an area of ongoing responsibility or a
  specific decision and hand it over to another Developer or to the
  Technical Committee.

  Once a particular decision has been delegated and made the Project
  Leader may not withdraw that delegation; however, they may
  withdraw an ongoing delegation of particular area of
  responsibility.

I would be very happy, if felt necessary by the Secretary, to delegate
that decision to the Technical Committee.

Lucas

signature.asc
Description: Digital signature

Bug#727708: Call for votes on init system resolution

Anthony Towns  writes:

> GR comparisons are:

>   UL > GR 5:1 (russ against)
>   UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
>   DL > GR 6:0

For whatever it's worth, I think this line is wrong.  I voted GR above DL.

>   DT > GR 4:2 (ian, andi against)

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


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

Bug#727708: Call for votes on init system resolution

Don Armstrong  writes:
> On Thu, 06 Feb 2014, Kurt Roeckx wrote:

>> So let me expand on that a little.  Image the following options
>> - A: something that doesn't overrule the ctte (1:1)
>> - B: something that does overrule the ctte (2:1)
>> - FD

> In this case, I don't know A could be anything but 2:1, baring riders
> from the CTTE. If A is technical, it needs the power of the CTTE under
> §4.1.4 which requires 2:1. [I suppose something could be written which
> would fall under the DPL's remit.]

> As I understand it, we'd like to make everything be 1:1, and the method
> we're trying is to write a proposal in such a way that it automatically
> enshrouds a non-technical statement by the project in the power of the
> CTTE.

> It may be that we can't actually do that, and should instead just have
> an agreement between CTTE members to enact a decision which followed a
> position statement GR under §4.1.5.

I think what we're trying to say looks something like this:

If the project holds a GR vote on the topic of the default init
system, the winning option of that vote replaces this text in its
entirety and becomes the decision of the Technical Committee.  The
winning option of the GR vote for this purpose will be decided
following the normal rules for deciding the outcome of a General
Resolution, with the exception that the 2:1 majority normally required
to overule the Technical Committee will not be taken into account.

I think this works, although it does create the possibility of a rather
odd situation, and I'm not quite sure how it would work procedurally.
Suppose that the project votes on a GR with the following imaginary
options:

A. The default init system for jessie will be [whatever the TC picked]
B. The default init system for jessie will be a single /etc/rc script

and suppose that B beats A beats FD, but B does not beat FD by a 2:1
majority.

The result of that GR is A.  However, the choice picked by the above
algorithm is B.  So B becomes the TC decision, despite the fact that A is
the result of the GR, and A, despite winning, now constitutes a TC
override and fails to go into effect.  Unless you think of A happening
"before" the TC decision changes, at which point the TC can no longer
override it?

It's weird.

One thing that would make it less weird is if the GR phrased whatever
option concurs with the TC as saying that the project upholds the TC
decision, rather than stating what that decision is.  Then, in the
scenario given above, A and B become the same as soon as the TC decision
is changed by the vote, and everything stays consistent.

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

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

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Anthony Towns

On 6 February 2014 11:20, Russ Allbery  wrote:
> I therefore intend to change my vote to list FD first iff Steve does the
> same, since I think it's up to him to decide whether he wants to stop,
> rework, and start again, or just continue on since the vote has started
> anyway.

The votes so far are:

 ian: UL DL OL VL GR *FD* UT OT VT DT
 andi: UL DL OL VL *FD* GR UT DT OT VT

 steve: UL DL *FD* OL VL UT DT OT=VT GR
 russ: DT GR DL UT *FD* OT VT UL OL VL
 colin: UL DL OL UT DT GR *FD* OT VL VT
 don: DT DL UT UL OT OL VT VL GR *FD*

 ian2: FD UL DL OL VL GR UT OT VT DT
 andi2: FD UL DL OL VL GR UT DT OT VT

With the initial vote, the following options are eliminated:

 OT, VT  (ian, andi, steve, russ vote these below FD)

With Ian and Andi's changed votes, the following options are eliminated:

 OL, VL (ian2, andi2, steve, russ vote these below FD)

That leaves UL, UT, DL, DT and GR still in the race against FD.

If Steve changes his vote to FD > *, and Russ does likewise as he's
stated, the vote will be decided as FD again.

If no one changes their vote, then, at present, the comparisons are:

  UL = FD 3:3 (steve, colin, don in favour; russ, ian2, andi2 against)
  UT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  DT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  GR = FD 3:3 (russ, colin, don in favour; steve, ian2, andi/andi2 against)

So those options will be eliminated if Bdale and Keith don't vote, or
if either Bdale or Keith vote them below FD.

  DL > FD 4:2 (ian2, andi2 against)

That can only be eliminated at this point if both Bdale and Keith vote
it below FD. It's the only option that had all six original votes
ranking it above FD.

(As it stands, DL would thus win the vote since all other options are
eliminated)

As it stands, that also means that Bdale and Keith could collude to
determine the outcome of the vote amonst {D,U}{L,T} by only voting the
option they prefer above FD.

GR comparisons are:

  UL > GR 5:1 (russ against)
  UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
  DL > GR 6:0
  DT > GR 4:2 (ian, andi against)

Rankings between remaning actual outcomes is:

  4x  UL > DL > UT > DT  (steve, colin, ian, andi)
  2x  DT > DL > UT > UL  (russ, don)

So that's

   UL > DL > DT  4:2
   UL > UT > DT  4:2
   DL > UT  6:0

It seems to me that if this ballot fails to FD, any future ballots
should skip options:

  OT, VT  (insufficient support over FD)
  OL, VL  (at least 6 of 8 committee members prefer UL and DL over
these options)

It seems unlikely that there's any actual support for UT, either.

Cheers,
aj

-- 
Anthony Towns 

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJS_LCVhLfgK9zi6PjrZnDQ8edd+qHYczG-=da79eh1pqtv...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

Russ Allbery writes ("Bug#727708: Call for votes on init system resolution"):
> To say explicitly to avoid making people read my mind: I think Kurt's
> concerns can be dealt with by a separate vote if necessary, so while I
> don't object to cancelling the vote for that, I'm also not sure it's
> necessary.

I would prefer to deal with this in the same resolution, as I have
already said.  I'm sorry that I didn't make sure Kurt was properly
involved in the drafting.

>  However, if Steve would like to cancel the vote to have more
> time to draft his compromise, I'm happy to do so.

For me, a desire to cancel the vote would follow directly from being
upset that the vote had started.  But this whole thread has
demonstrated to me in many ways that what I think is obvious is far
from uncontentious.

> I therefore intend to change my vote to list FD first iff Steve does the
> same, since I think it's up to him to decide whether he wants to stop,
> rework, and start again, or just continue on since the vote has started
> anyway.
> 
> I'm open to being convinced that I have this backwards and should just
> change my vote now.

I think Steve's failure to rank FD first is probably a procedural
error on his part.  I've tried to catch him on IRC but not had a clear
response yet.

Or perhaps he feels it would be rude to rank FD first to try to vote
down what he felt was a premature CFV.  But as I have said I think
that's exactly what FD is for.  FD means precisely "further
discussion".  So, Steve, if that's what's holding you back please do
change your vote.

Ian.


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

Bug#727708: Call for votes on init system resolution

Ian Jackson  writes:

> The only change is to rank FD first.  I think we should give Steve a
> chance to draft his compromise, and also to satisfy Kurt.

> I encourage others to do likewise.  If Steve and one other person
> does this then this vote too will be cancelled.

To say explicitly to avoid making people read my mind: I think Kurt's
concerns can be dealt with by a separate vote if necessary, so while I
don't object to cancelling the vote for that, I'm also not sure it's
necessary.  However, if Steve would like to cancel the vote to have more
time to draft his compromise, I'm happy to do so.

I therefore intend to change my vote to list FD first iff Steve does the
same, since I think it's up to him to decide whether he wants to stop,
rework, and start again, or just continue on since the vote has started
anyway.

I'm open to being convinced that I have this backwards and should just
change my vote now.  Also, I'm happy to change my vote if Kurt disagrees
with the idea that we can fix his concerns in a subsequent vote and feels
like the vote should not continue.

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

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

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Don Armstrong

On Thu, 06 Feb 2014, Kurt Roeckx wrote:
> So let me expand on that a little.  Image the following options
> - A: something that doesn't overrule the ctte (1:1)
> - B: something that does overrule the ctte (2:1)
> - FD

In this case, I don't know A could be anything but 2:1, baring riders
from the CTTE. If A is technical, it needs the power of the CTTE under
§4.1.4 which requires 2:1. [I suppose something could be written which
would fall under the DPL's remit.]

As I understand it, we'd like to make everything be 1:1, and the method
we're trying is to write a proposal in such a way that it automatically
enshrouds a non-technical statement by the project in the power of the
CTTE.

It may be that we can't actually do that, and should instead just have
an agreement between CTTE members to enact a decision which followed a
position statement GR under §4.1.5.

-- 
Don Armstrong  http://www.donarmstrong.com

Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
http://www.asofterworld.com/index.php?id=481

--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206004854.gd5...@teltox.donarmstrong.com

Bug#727708: Call for votes on init system resolution

Ian Jackson  writes:

> Options on the ballot:

>   DT   systemd default in jessie, requiring specific init is allowed
>   DL   systemd default in jessie, requiring specific init NOT allowed

>   UT   upstart default in jessie, requiring specific init is allowed
>   UL   upstart default in jessie, requiring specific init NOT allowed

>   OT   openrc default in jessie, requiring specific init is allowed
>   OL   openrc default in jessie, requiring specific init NOT allowed

>   VT   sysvinit default in jessie, requiring specific init is allowed
>   VL   sysvinit default in jessie, requiring specific init NOT allowed

>   GR   project should decide via GR

>   FD   further discussion

I vote:

DT GR DL UT FD OT VT UL OL VL

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


pgph080OprmMA.pgp
Description: PGP signature

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 12:32:53AM +0100, Kurt Roeckx wrote:
> On Wed, Feb 05, 2014 at 11:09:25PM +, Ian Jackson wrote:
> > Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > > I'm not sure I like the way this is worded, I would have prefered
> > > that you asked me about this before calling for votes.
> > 
> > So assuming that the current vote is cancelled due to 4 people ranking
> > FD first: would you care to say what the wording should be ?  I don't
> > think any of us care very much about this wording and we all agree
> > about the intent, so it shouldn't be controversial.
> 
> My biggest concern is that you can only do this if the result of
> the GR is FD.

So let me expand on that a little.  Image the following options
- A: something that doesn't overrule the ctte (1:1)
- B: something that does overrule the ctte (2:1)
- FD

If option B would win but is dropped because of the 2:1 majority
and option A wins instead the project would have made a decision
and you can't overrule that anymore.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205235618.gb13...@roeckx.be

Re: Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 12:40:22AM +0100, Philipp Kern wrote:
> 
> I'd prefer if CTTE members would actually sign their votes. (But I
> guess it's up to the secretary.)

I've actually asked that they do that before, but it's not really
a requirement.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205234631.ga13...@roeckx.be

Re: Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Philipp Kern


On 2014-02-05 17:36, Ian Jackson wrote:
Ian Jackson writes ("Bug#727708: Call for votes on init system 
resolution"):

I hereby call for votes on my previously proposed resolution and
amendments.  All the options require a simple majority.


I vote:

 1.  UL   upstart default in jessie, requiring specific init NOT 
allowed
 2.  DL   systemd default in jessie, requiring specific init NOT 
allowed

 3.  OL   openrc default in jessie, requiring specific init NOT allowed
 4.  VL   sysvinit default in jessie, requiring specific init NOT 
allowed

 5.  GR   project should decide via GR
 6.  FD   further discussion
 7.  UT   upstart default in jessie, requiring specific init is allowed
 8.  OT   openrc default in jessie, requiring specific init is allowed
 9.  VT   sysvinit default in jessie, requiring specific init is 
allowed

 10. DT   systemd default in jessie, requiring specific init is allowed


I'd prefer if CTTE members would actually sign their votes. (But I guess 
it's up to the secretary.)


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/23d5e36d8b3c05fd9b6fa9d8d1ceb...@hub.kern.lc

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 11:09:25PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I'm not sure I like the way this is worded, I would have prefered
> > that you asked me about this before calling for votes.
> 
> So assuming that the current vote is cancelled due to 4 people ranking
> FD first: would you care to say what the wording should be ?  I don't
> think any of us care very much about this wording and we all agree
> about the intent, so it shouldn't be controversial.

My biggest concern is that you can only do this if the result of
the GR is FD.  It should be more explicit that if the option is
trying to override the ctte but failed to reach the 2:1 majority
requirement you will re-evaluate the results with the 2:1 majority
requiremented to override the ctte changed to 1:1 and adopt the
outcome of that (which might still be FD).

Kurt

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205233253.ga13...@roeckx.be

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> I'm not sure I like the way this is worded, I would have prefered
> that you asked me about this before calling for votes.

So assuming that the current vote is cancelled due to 4 people ranking
FD first: would you care to say what the wording should be ?  I don't
think any of us care very much about this wording and we all agree
about the intent, so it shouldn't be controversial.

Thanks,
Ian.


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

Bug#727708: Call for votes on init system resolution

I hereby change my vote:

1.  FD   further discussion
2.  UL   upstart default in jessie, requiring specific init NOT allowed
3.  DL   systemd default in jessie, requiring specific init NOT allowed
4.  OL   openrc default in jessie, requiring specific init NOT allowed
5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
6.  GR   project should decide via GR
7.  UT   upstart default in jessie, requiring specific init is allowed
8.  OT   openrc default in jessie, requiring specific init is allowed
9.  VT   sysvinit default in jessie, requiring specific init is allowed
10. DT   systemd default in jessie, requiring specific init is allowed

The only change is to rank FD first.  I think we should give Steve a
chance to draft his compromise, and also to satisfy Kurt.

I encourage others to do likewise.  If Steve and one other person
does this then this vote too will be cancelled.

Thanks,
Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Paul Tagliamonte

On Wed, Feb 05, 2014 at 10:29:09PM +, Colin Watson wrote:
> The original request to us was made by Paul Tagliamonte, who I don't
> think is on the d-i team (or if he is I hope he'll forgive me for
> observing he isn't very active).

FTR - I'm not on the d-i team, and havn't been. No worries :)

> The only people who might reasonably be described as vaguely current
> maintainers of parts of d-i whom I can immediately find on a quick scan
> of the early parts of this bug are Wouter and myself; Tollef also
> contributed a good deal in the past, and I may have missed one or two.
> But I don't think any of these people have been acting as d-i
> maintainers here.  People like Cyril and Christian, who would be more
> obvious candidates for such a label, have not commented on this bug.
> 
> I would have thought that this is more clearly handled under 6.1(2)
> ("Decide any technical matter where Developers' jurisdictions overlap").

I agree here. I think I quoted this in a followup after I figured out my
initial mail was contentless:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;att=0;bug=727708

| It is requested that the tech-ctte make a decision as to the init system
| Debian shall use as the default, and make a judgement call on where the
| efforts to resolve this situation shall go (patching *around* the lack
| of systemd, or patching software to use systemd)
| 
| I believe this is within the ctte's jurisdiction, given 6.1 section 2.

The TC is of course fully within it's rights to tweak under which
sections it rules.

Cheers,
  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

Bug#727708: Call for votes on init system resolution

Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
> I vote:
> 
>  1.  UL   upstart default in jessie, requiring specific init NOT allowed
>  2.  DL   systemd default in jessie, requiring specific init NOT allowed
>  3.  FD   further discussion

If you are serious about wanting to discuss the drafting further, you
should vote FD first

Ian.


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

Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> Please do not assume I have time to read everything.  I don't.  I
> actually think I gave advice about this before which you seem to
> have ignored.

I'm sorry if I also missed a mail.

> > Anyway, I think as regards T vs L we are chiefly exercising our power
> > to set technical policy.  As regards the default init system we are
> > making a decision which has been requested of us by the people
> > normally responsible (which would be the d-i maintainersI think).
> 
> I would like to point out that this was requested by Paul
> Tagliamonte, who as far as I know is not in the d-i team.  I
> didn't see anybody from the d-i team request that you make a
> decision for them, but I might have missed that.

I assume you would like us to cancel the current vote and address
these points.

Ian.


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

Bug#727708: Call for votes on init system resolution

Steve Langasek writes ("Re: Bug#727708: Call for votes on init system 
resolution"):
> I am very unhappy to see this CFV in my inbox this morning.

I'm sorry about that.

>  I made it known that I was not satisfied with the set of ballot
> options, and I was still in the process of drafting language to try
> to identify a consensus position

You mean your message of "Sat, 1 Feb 2014 15:34:08 -0500", I take it.

That was after the formal proposal had been made.  So it was open to
you to formally propose an amendment.

In response to that message:
 * Don and Russ (who didn't like L) said that your proposed S was no
   better than L.
 * I (who don't like T) said that your proposed S was like a version
   of T for me.
 * I explicitly asked you (at Sun, 2 Feb 2014 09:34:45 +)
   whether you wanted to delay the vote for redrafting, formally
   propose some version of your S, or something else.

I don't remember seeing a warning in your mail of the 1st of February
that you would be out of touch and that we should not call for a vote.
In the absence of such a respose from you, I didn't get the impression
you were wanting a delay.  Neither I think did anyone else.

The original plan was to call for a vote on Monday.  We delayed this
for two days because of other amendments following comments.

>  I don't think it's reasonable to give a
> 48-hour deadline, during a work week, in the body of one message among
> dozens.  With nothing to call attention to itself, that message sat unread
> in my box among a pile of others until just now, when it's too late.

The whole of the body text was this:

  Ian Jackson writes ("Bug#727708: package to change init systems"):
  > I would be happy to do this.  Anyone object to me prefixing
  >Therefore, for jessie and later releases:
  > before the T/L "Software ..." paragraphs ?

  Following another exchange on IRC I have now done this in git, and I
  hereby propose and accept that amendment (to all versions).  The
  result is as below.

  I now intend to do the CFV at 16:30 UTC on Wednesday.

  Thanks,
  Ian.

I'm sorry if that wasn't sufficiently clear.  Perhaps I should have
changed the Subject too.

> This is substantially the same as Bdale's earlier CFV, which you objected to
> at the time.

Unlike Bdale's CFV this one:
 - includes the agreed GR rider;
 - had a nonzero discussion period; indeed a discusson period of
   nearly a week, during which any TC member could have ensured that
   any options of their choice were on the ballot by proposing them;
   (those two were my procedural objections); and
 - includes some answer to the coupling question (which was my
   substantive objection).

> Since this vote will almost certainly result in a resolution passing, I
> think I will need to begin drafting a follow-up resolution to address this,
> under 6.1.1.

That's your privilege of course.

Under the circumstances I'm quite prepared to give you a chance to do
the drafting work you want to do.  Particularly since Kurt has
objected too.

Ian.


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

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Paul Tagliamonte

On Wed, Feb 05, 2014 at 05:28:41PM -0500, Michael Gilbert wrote:
> paultag made the request while referencing 6.1.2 as the relevant
> clause.  He isn't involved in d-i.

(Heyya, mgilbert! :) )

I brought it forward under that clause because it made sense at the
time, but I think the TC is free to consider this a matter of technical
policy, it' not unreasonable to peg this as a policy issue.

Anyway, I'm not sure where this lies, and I trust the TC to DTRT.

(Just FTR, I really don't want to hold up voting, I think we've all had
 enough of this and we just need a decision that we can gel around rather
 then keeping this fight up - we're all pretty bloody after this one.)

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

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Thorsten Glaser

Colin Watson dixit:

>> https://lists.debian.org/debian-devel/2014/02/msg00106.html
>
>Various developers certainly continue to work enthusiastically on their
>preferred approaches, but that's not really the same as "efforts to
>resolve [the issue] via consensus".

But is not diversity some sort of consensus too? Let’s just support
all of them…

>I would say that a couple of years
>of vehement debate spread across various mailing lists with developers
>settling into increasingly entrenched positions on all sides is rather
>the opposite of movement towards a consensus position.

Eh… if you put it like that… ok…

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (269 (292) bugs: 0 RC, 188 (204) I&N, 81 (88) M&W, 0 F&P)
‣ src:dash (89 (106) bugs: 2 RC, 43 (49) I&N, 44 (55) M&W, 0 F&P)
‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1402052241440.6...@herc.mirbsd.org

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Thorsten Glaser

Colin Watson dixit:

>("Decide any technical matter where Developers' jurisdictions overlap").

I think it is not up to the d-i people to decide on the init system
anyway – especially as not d-i but debootstrap is the canonical way
to install Debian… and debootstrap goes by whatever ftp-masters put
into the override files, and whatever package dependencies and meta
information (such as Essential: yes) there are.

So, “jurisdiction overlaps” seems to fit quite well.

bye,
//mirabilos (waiting on the decision outcome before proposing a GR)
-- 
 Ach, mach doch was du willst, du hast doch eh immer Recht!
 jupp ~/.etc/sig………
 unfaßbar…
 Mit Eszett sogar, unfaßbar!


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1402052239190.6...@herc.mirbsd.org

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Colin Watson

On Wed, Feb 05, 2014 at 05:08:35PM -0500, Michael Gilbert wrote:
> The big question, I think, is whether section 6.3.6 of the
> constitution has been satisfied.  The project is still clearly working
> on solutions, but at a slower pace than some may desire.  See this for
> a recent example:
> https://lists.debian.org/debian-devel/2014/02/msg00106.html

Various developers certainly continue to work enthusiastically on their
preferred approaches, but that's not really the same as "efforts to
resolve [the issue] via consensus".  I would say that a couple of years
of vehement debate spread across various mailing lists with developers
settling into increasingly entrenched positions on all sides is rather
the opposite of movement towards a consensus position.

No doubt this would be for the secretary to adjudicate, though, under
7.1(3).

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205223823.gb3...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 10:05:45PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I would really like it that you indicated under which power the
> > CTTE is making decisions, and the majority requirements that go
> > with that the options, for all your votes.
> 
> Sorry not to give you an explicit heads-up about this resolution.  (It
> has been proposed in this form for some time now though.)

Please do not assume I have time to read everything.  I don't.  I
actually think I gave advice about this before which you seem to
have ignored.

> Anyway, I think as regards T vs L we are chiefly exercising our power
> to set technical policy.  As regards the default init system we are
> making a decision which has been requested of us by the people
> normally responsible (which would be the d-i maintainersI think).

I would like to point out that this was requested by Paul
Tagliamonte, who as far as I know is not in the d-i team.  I
didn't see anybody from the d-i team request that you make a
decision for them, but I might have missed that.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205223540.ga11...@roeckx.be

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Colin Watson

On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote:
> I hereby call for votes on my previously proposed resolution and
> amendments.  All the options require a simple majority.

I vote:

  1. UL   upstart default in jessie, requiring specific init NOT allowed
  2. DL   systemd default in jessie, requiring specific init NOT allowed
  3. OL   openrc default in jessie, requiring specific init NOT allowed
  4. UT   upstart default in jessie, requiring specific init is allowed
  5. DT   systemd default in jessie, requiring specific init is allowed
  6. GR   project should decide via GR
  7. FD   further discussion
  8. OT   openrc default in jessie, requiring specific init is allowed
  9. VL   sysvinit default in jessie, requiring specific init NOT allowed
 10. VT   sysvinit default in jessie, requiring specific init is allowed

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205223210.ga28...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Colin Watson

On Wed, Feb 05, 2014 at 10:05:45PM +, Ian Jackson wrote:
> As regards the default init system we are making a decision which has
> been requested of us by the people normally responsible (which would
> be the d-i maintainersI think).

The original request to us was made by Paul Tagliamonte, who I don't
think is on the d-i team (or if he is I hope he'll forgive me for
observing he isn't very active).

The only people who might reasonably be described as vaguely current
maintainers of parts of d-i whom I can immediately find on a quick scan
of the early parts of this bug are Wouter and myself; Tollef also
contributed a good deal in the past, and I may have missed one or two.
But I don't think any of these people have been acting as d-i
maintainers here.  People like Cyril and Christian, who would be more
obvious candidates for such a label, have not commented on this bug.

I would have thought that this is more clearly handled under 6.1(2)
("Decide any technical matter where Developers' jurisdictions overlap").

-- 
Colin Watson   [cjwat...@debian.org]

-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205222909.ga3...@riva.ucam.org

Bug#727708: Call for votes on init system resolution

2014-02-05 Thread Michael Gilbert

On Wed, Feb 5, 2014 at 5:05 PM, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
>> I would really like it that you indicated under which power the
>> CTTE is making decisions, and the majority requirements that go
>> with that the options, for all your votes.
>
> Sorry not to give you an explicit heads-up about this resolution.  (It
> has been proposed in this form for some time now though.)
>
> Anyway, I think as regards T vs L we are chiefly exercising our power
> to set technical policy.  As regards the default init system we are
> making a decision which has been requested of us by the people
> normally responsible (which would be the d-i maintainersI think).

paultag made the request while referencing 6.1.2 as the relevant
clause.  He isn't involved in d-i.

6.1.2 is supposed to be about resolving "incompatible policies or
stances".  The particular vote proposed here dictates a specific
direction for the project, and doesn't actually do anything about init
system incompatibilities, so its not clear at least to me that 6.1.2
is appropriate.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mo0nfnv807960qbaqjfsuogtcouyk0cxati55kptcn...@mail.gmail.com

Bug#727708: Call for votes on init system resolution