date:20140208

Steve Langasek vor...@debian.org writes:

 So to make my position clear:  L does not accurately reflect what I
 think we should be doing; but given the option between L and T, I was
 willing to vote L above FD and was not willing to vote T above FD
 because I think T unambiguously sets the stage for all other init
 systems to wither away in Debian and I think it's foolish for the TC to
 say they are welcome under such circumstances.

I completely understand how you would end up in that situation.

 Here's what I think is the right technical policy, that we should be
 addressing with this resolution.

  - Packages in jessie must retain compatibility with sysvinit startup
interfaces (i.e., init scripts in /etc/init.d).
  - Packages can require other interfaces for their operation that are
provided by an init system implementation, but which are unrelated to
service management; however, these requirements must be expressed in a
way that does not tie them to a single init system package.  E.g., a
package that uses the logind dbus interfaces is absolutely free to do so,
but must not express this usage as 'Depends: systemd'.
  - The TC should make no ruling at this time regarding releases beyond
jessie.

Here is the language that I came up independently of (and before) your
message, which I think demonstrates how close we actually are on this
point.

The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution.  It does
not constitute an override of maintainer decisions past or future:

Packages should normally support the default Linux init system.  There
are some exceptional cases where lack of support for the default init
system may be appropriate, such as alternative init system
implementations, special-use packages such as managers for non-default
init systems, and cooperating groups of packages intended for use with
non-default init systems.  However, package maintainers should be
aware that a requirement for a non-default init system will mean the
package will be unusable for most Debian users and should normally be
avoided.

Package maintainers are strongly encouraged to merge any contributions
for support of init systems other than the Linux default, and to add
that support themselves if they're willing and capable of doing so.
In particular, package maintainers should put a high priority on
merging changes to support any init system which is the default on one
of Debian's non-Linux ports.

For the jessie release, all packages that currently support being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve or
improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and the
package is still basically functional.  All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.

The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release.  There are too many variables at this point to know what the

I think this is broadly similar to what you propose above.  The
differences I can identify are:

* I don't explicitly require that all dependencies on non-init
  functionality provided by the init system be redirected through a
  virtual package immediately.  I think this is an implementation detail;
  I don't have fundamental objections to your language, but I do think
  it's overspecified.  I think we get to the same place with the above
  advice, combined with the stronger advice for jessie.

* We deal with the question of what happens if logind without systemd
  fails to materialize in slightly different ways.  I approach that with
  the technically feasible language, and you approach that by allowing
  for a dependency that can only be satisfied by one package.  I think
  either of those are reasonable approaches.  My language tries to avoid
  specifying the technical solution and instead tries to state the desired
  result.

In general, I would be happy to use my language, your language, or some
merger between them.  There are some things I prefer about how I put this,
but the only thing that I'd really like to change is to give the
maintainer some discretion over your first bullet.  You sort of do this
already by saying retain rather than saying that packages must support
sysvinit, but I think I was somewhat clearer.  I don't see any reason why,
say, mountall or socklog-run should be required to support sysvinit.

My statement is written using 6.1.5 because it sidesteps the whole issue
of delegations and whatnot and I think should be

Bug#727708: Call for votes on init system resolution

Russ Allbery r...@debian.org writes:

 The Technical Committee offers no advice at this time on requirements
 or package dependencies on specific init systems after the jessie
 release.  There are too many variables at this point to know what the

Sorry, cut and paste error.  The entire intended paragraph there was:

The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release.  There are too many variables at this point to know what the
correct course of action will be.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/877g95nxog@windlord.stanford.edu

Bug#727708: Call for votes on init system resolution

Colin Watson cjwat...@debian.org writes:

 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.

It's been a really long thread, and I think we're all running low on
spoons.  It's clear that I should have pushed a bit harder on some points
that Ian indicated continued disagreement with rather than assuming his
disagreement was echoed by you, Steve, and Andi.

 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.

Oh, yes, absolutely.  I agree with most of L for jessie as long as we
carve out a few reasonable exceptions.  I think I proposed limiting L to
jessie somewhere in the thread, Ian disagreed, and I dropped it.  I'd be
very happy to resurrect something akin to that.

 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?

Yes.

I don't think the GNOME maintainers, to take a concrete example, should be
required to make that support appear if it doesn't exist.  But so long as
someone provides a logind-compatible service that doesn't require systemd,
it certainly seems reasonable to me to advise the GNOME maintainers to
allow it to satisfy the dependencies of GNOME.  My impression is that none
of the GNOME maintainers object to this idea, only to the assumption that
such a service will necessarily materialize and that it's therefore
reasonable to flatly require they not depend on systemd.  If things go as
both you and Steve expect them to go, this whole problem simply
disappears, and is replaced with some technical work about how best to
represent the dependency structure, source packages, and so forth, which
I'm confident can be resolved amicably by all parties.

 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.

I think one of the problems that we ran into was that we ended up
entangling what init system configuration the package ships with and the
whole logind issue, and they're really somewhat separate issues with
different long-term dynamics.

 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.

I completely agree with this.  I think there's some reasonable chance
that, a year or two from now, things will have sorted out sufficiently
that we can reach a normal project consensus on where to go next.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/8738jtnx7k@windlord.stanford.edu

Bug#727708: Call for votes on init system resolution

2014-02-08 Thread Adrian Bunk

On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote:
...
 I don't see any reason why,
 say, mountall or socklog-run should be required to support sysvinit.
...

What about udev?

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/20140208212759.gb9...@bunk.dyndns.info

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

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

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

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

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

 - - - start ballot - - -

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

   Dsystemd 
   Uupstart
   Oopenrc
   Vsysvinit (no change)
   Frequires further discussion

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

I vote F U D O V

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

  U F O V D

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

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


signature.asc
Description: Digital signature

Re: Additional CTTE Drafting Meeting useful?

On Wed, Feb 05, 2014 at 05:02:46PM -0800, Don Armstrong wrote:
 Would one more IRC meeting be useful to nail down the ballot options and
 their drafts?

 Our next scheduled meeting is the 27th of February, but we could have
 one on the 13th or earlier at the usual time if that worked for
 everyone.

 I can do the following dates:

snip
 February 14 2014 18:00:00 GMT
snip

I'm not opposed to a realtime drafting session, but the above is the only
one of the proposed times that works for me.

I also think having a drafting session that doesn't have representation of
the full range of opinions from the TC is likely to be counterproductive; it
allows for rapid iteration on ballot options, but to little effect if those
options don't actually have consensus behind them.

So I think on-list drafting is probably best here.

-- 
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 default Linux init system for jessie

Steve Langasek vor...@debian.org writes:

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

Given that you feel like it's clear what the default init system will be,
and given that the previous rounds of partial voting show that the choice
of dependency models will have no effect on that outcome, I don't see any
point in delaying this part of the decision.  You feel like this is all
but decided; fine, let's decide it, so that we have a decision on record,
and then continue the discussion.

Or, put another way, why *don't* you want to vote on this right now?  That
it's not the most important question is not a reason to delay voting on
it; if anything, it's a reason to vote on it first, so that we can dispose
of the questions with clear answers while we're working on language for
the more complex options.

We held the ballot to entangle it with other questions on the assumption
that this entangling may change the result for the primary question.  It
turns out that this is not the case, so there was no need for that
entangling.  I would really like to establish things that you think are
already apparent so that we have some forward progress and so that we
don't have to hold open sockets for things that we think are *probably*
decided but that we've not yet actually decided.

If you feel like deciding this will mean losing some momentum on a
question that you consider more important, I personally commit to
continuing the discussions on that process and working on a ballot and
arriving at a decision as quickly as possible.  I don't think any of us
intend to abandon this discussion once the init system default on Linux is
decided.

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

I think a group of DDs are telling us that we're not doing our job in a
timely fashion.  While one may or may not agree with that, I think it's
intended as constructive feedback, and personally I welcome the
accountability to the rest of the project here.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/877g95me4s@windlord.stanford.edu

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

2014-02-08 Thread Bdale Garbee

Steve Langasek vor...@debian.org writes:

 I will note for the record here that a number of DDs have at this point
 given the TC an ultimatum in private, stating that they will start a GR if
 the TC does not call for votes within a specified time limit.  I suspect
 that this ultimatum didn't have much effect on Bdale's decision to call for
 a vote (since he was already predisposed to having the up/down vote in
 question).

That is correct.  I had already posted the call for votes on this ballot
before I discovered that email in my inbox.

I'm disappointed, particularly since you seem inclined to agree that the
outcome of the simple part of this vote really isn't in question any
more, that you've chosen to vote F first.  That's certainly your right,
but I do hope you will reconsider.

Bdale


pgpHYJGY60do_.pgp
Description: PGP signature

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

2014-02-08 Thread Keith Packard

Steve Langasek vor...@debian.org writes:

 I agree with Ian on this.  At this point, it should be clear to everyone
 that, given the stated preferences of each member of the TC, the default
 init system for jessie will be systemd.

Let's finish that vote then and move on.

 But I do not think this is the most important aspect of the problem
 that needs to be decided.  The question of how, or if, multiple init
 systems will coexist in the Debian archive for jessie is what needs to
 be decided in order to unblock maintainers and give them clarity for
 their own packages.

That is an entirely separate issue. I agree that it is important and
needs to be resolved, but the Technical Committee is the wrong place to
be designing this policy. We must (by 6.3.5) not engage in design of new
proposals and policies.

Yes, as individuals, we may choose to collaborate with others on the
development of a suitable policy, and that group may well decide that
they cannot reach a consensus and bring the issue back to the Technical
Committee for advice. Please stop trying to bypass the constitutional
process for policy design.

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


pgpSk8XKMt3cv.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

2014-02-08 Thread Don Armstrong

On Sat, 08 Feb 2014, Bdale Garbee wrote:
 - - - start ballot - - -
 
 We exercise our power to decide in cases of overlapping jurisdiction
 (6.1.2) by asserting that the default init system for Linux
 architectures in jessie should be
 
   Dsystemd 
 
   Uupstart
 
   Oopenrc
 
   Vsysvinit (no change)
 
   Frequires further discussion
 
 Should the project pass a General Resolution before the release of
 jessie asserting a position statement about issues of the day on
 init systems, that position replaces the outcome of this vote and is
 adopted by the Technical Committee as its own decision.
 
 - - - end ballot - - -

I vote D  U  O  V  F.

I also agree that given that while the additional questions of how
packages are able to depend or rely on the default init system is
important, it is not necessary to resolve that question to determine
which system is going to be the default init system, as in no ballot yet
has anyone changed their D/U ranking on the basis of which of the T, S,
or L options were being voted for.

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

There is no form of lead-poisoning which more rapidly and thoroughly
pervades the blood and bones and marrow than that which reaches the
young author through mental contact with type metal.
 -- Oliver Wendell Holmes (Tilton 1947 p67)


-- 
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/20140208225113.gl5...@teltox.donarmstrong.com

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

2014-02-08 Thread Joerg Jaspert

On 13481 March 1977, Steve Langasek wrote:

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

While threats are nothing useful, at this point in time anything that
makes the basic question that the CTTE was asked, Which init system?,
be answered later, is bad. No, its worse than that.

Basically it undermines any kind of authority or respect the CTTE (not
single individual members, the whole thing) has/had in the
project. Dragging this one only makes it worse.

Its not understandable why the heck there cant be a simple vote between
the various init systems now and whatever other votes on whatever
statement around this area later. Especially when we read Its clear
that systemd would win. So make it win, let the project move on, thats
important.

The project wants to know, now, if we go with systemd, openrc, upstart
or none of them. Any details arising from that, wich the ctte may feel
they should decide on, are not important now. One simple vote is. Not
combnining trillions of options into the most convoluted ballot possible.

Right now this is a disgrace for the whole project.

-- 
bye, Joerg


-- 
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/87mwi1kydr@lennier.ganneff.de

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

Keith Packard kei...@keithp.com writes:

 That is an entirely separate issue. I agree that it is important and
 needs to be resolved, but the Technical Committee is the wrong place to
 be designing this policy. We must (by 6.3.5) not engage in design of new
 proposals and policies.

Well, in defense of the discussion that Steve, Colin, and I have been
having, I do think it's worthwhile for the TC to try to hammer out a
compromise on that point as well and express it as either technical advice
to the project or as technical policy.

While it may not have been explicitly listed in the message that referred
this debate to the TC, the question of logind dependencies and the
question of how to handle packages that no longer support a
lowest-common-denominator sysvinit script have come up repeatedly in the
interminable debian-devel discussions on this topic.  I believe they're
controversial questions and that we'd benefit from hashing out a
reasonable approach in the TC context and offering it as advice.

I also don't think that the approaches that we're discussing at the moment
involve design work or are at all novel.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/8738jtmcwm@windlord.stanford.edu

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

On Sat, Feb 8, 2014 at 5:55 PM, Joerg Jaspert wrote:
On 13481 March 1977, Steve Langasek wrote:

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

While threats are nothing useful, at this point in time anything that
makes the basic question that the CTTE was asked, Which init system?,
be answered later, is bad. No, its worse than that.

Basically it undermines any kind of authority or respect the CTTE (not
single individual members, the whole thing) has/had in the
project. Dragging this one only makes it worse.

I find it far more respectable for the TC to be slow and deliberate
when they act. It is very difficult to solve the hard problems, and
that necessitates time.

Pressuring the TC to act is just plain wrong, and double so if done as
an attempt to placate the sideline observers (the LWNs, Phoronices,
etc.).

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=mmvfd0+6vu3b7o378naekzjpqpj5uknrff3q-mt_hz...@mail.gmail.com

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

2014-02-08 Thread Keith Packard

Russ Allbery r...@debian.org writes:

 Well, in defense of the discussion that Steve, Colin, and I have been
 having, I do think it's worthwhile for the TC to try to hammer out a
 compromise on that point as well and express it as either technical advice
 to the project or as technical policy.

I'm really pleased that the three of you have constructed a policy that
looks like a good compromise for this problem. I was worried that this
would also become mired in controversy, when in fact there is already
broad agreement and consensus.

 I also don't think that the approaches that we're discussing at the moment
 involve design work or are at all novel.

It's not sophisticated or novel, but you're definitely crafting new
policy for the project. Given that the group doing this are likely to
reach consensus, it sounds like the Technical Committee process will not
be necessary in this case. And I think we'll all be pleased if that
happens.

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


pgpeyr7GFgSnn.pgp
Description: PGP signature

Bug#727708: Both T and L are wrong, plea for something simpler

On Sat, Feb 08, 2014 at 06:15:52PM +0100, Kurt Roeckx wrote:
 On Sat, Feb 08, 2014 at 05:45:19PM +0100, Bill Allombert wrote:
  On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote:
   On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote:
Didier 'OdyX' Raboud o...@debian.org writes:

 Back then, the gnome maintainers added a dependency on another
 package, which happened to be providing an /sbin/init.  This was
 allowed by the Debian Policy of the time as well as by the Debian
 archive.  The maintainers of the Policy maintainers haven't tried
 to rule on this at all since then.  How is this matter now
 magically taken off the Policy maintainers' hands (while it _is_ a
 matter of Policy) and become a matter for the technical committee?

   It would be nice that other members from the policy tean could
   agree to that.

  The policy maintainers job is to maintain the policy document, not
  to adjudicate conflicts. 

 I would have to disagree with that.  The recent delegation among
 other things says defines [...] technical requirements that all
 packages must satisfy.  What the ctte here wants to do is set
 policy about having a Depends on an init system.  Under the
 delegation I think this is something for the policy editors to
 decide.

I question the whole notion of DPL delegation of policy powers to the policy
editors.  The power to decide the contents of the debian-policy package
follows from their status as package maintainers; package maintenance is not
something that I believe it's in the purview of the DPL to delegate.

What happens if the TC disagrees with the DPL's choice of policy
maintainers, and exercises its power under 6.1.2 to name different package
maintainers?  Since this is a power expressly given to the TC, I think a
consistent interpretation of the constitution requires that the DPL does not
have the authority to make such a delegation.  The alternative
interpretation is that we have a baked-in constitutional crisis, which I
don't believe is the intent.

I'm not arguing that I don't think the policy editors are doing a good job -
I'm grateful to them for the work they do.  But constitutionally, I think
the DPL doesn't have any authority to delegate the power to decide technical
policy (which is a power reserved to the TC in the absence of consensus),
only the power to act as recognized facilitators for policy discussions
(i.e., the previous delegation that was in place).

 What is going on here is that as policy editors you need to set
 policy and that the ctte here is setting policy instead of you.
 The question has been asked that it is at this time allowed for
 them to do so.  It's not up to the ctte to do detailed design
 work, and that they should decide between the options discussed
 somewhere else if they can not come to a consensus.  It has been
 argued that this has not been discussed somewhere else, and so
 that it's not yet up to the ctte to decide this.

 What I understand that Russ is now saying is that if this was
 brought to the policy team, he would refer it to ctte.  As
 delegate he can decide this on his own, but it would be nice
 that the other delegates didn't disagree with that.

This much is reasonable, whether the policy editors' authority is delegated
or not.

-- 
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 default Linux init system for jessie

On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:
 Keith Packard writes:

 That is an entirely separate issue. I agree that it is important and
 needs to be resolved, but the Technical Committee is the wrong place to
 be designing this policy. We must (by 6.3.5) not engage in design of new
 proposals and policies.

 Well, in defense of the discussion that Steve, Colin, and I have been
 having, I do think it's worthwhile for the TC to try to hammer out a
 compromise on that point as well and express it as either technical advice
 to the project or as technical policy.

Why not hammer that out on -policy in public, and only if something
goes wrong there, then defer it to the TC?

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=MPT=abtv+5vpe9aevqq3hivpl6xk3e1yr6-n+x5htv...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

Michael Gilbert mgilb...@debian.org writes:
 On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:

 Well, in defense of the discussion that Steve, Colin, and I have been
 having, I do think it's worthwhile for the TC to try to hammer out a
 compromise on that point as well and express it as either technical
 advice to the project or as technical policy.

 Why not hammer that out on -policy in public, and only if something goes
 wrong there, then defer it to the TC?

Because -policy doesn't have a decision-making process other than
consensus, so Ian's objections to all of the positions shy of L and my
objections to L would deadlock and effectively block the -policy
discussion from ever reaching a decision.  There is no method for either
of us to be overridden.

Now, there would have been no way of knowing in advance that something
like that would happen... but based on my past experience with Policy
discussions and the level of controversy over this particular question, I
would have been stunned if it hadn't happened, which is exactly why I
would have immediately punted to the TC.

Policy doesn't have a strong decision-making method other than consensus,
which means that it will fail to arrive at a conclusion for anything
that's even vaguely controversial (and sometimes even for things that are
not very controversial but which don't inspire people to express an
opinion).  Maybe that's a bug that should be fixed, or maybe we should
just use the TC as the way of reaching conclusions on controversial
issues; I can see arguments either way.  (The first Policy issue that I
escalated to the TC as an experiment in using the TC to make these
decisions was decided but was never implemented, and the second is still
pending before the TC, so the track record here is not great, for a
variety of reasons.)  But as matters stand right now, there's no way for
the Policy process to reach a conclusion on questions like this.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87mwi1kx36@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

On Sat, Feb 08, 2014 at 05:46:07PM -0500, Paul Tagliamonte wrote:
  This should not be our priority.  Our purpose
  here is to make sound technical decisions on behalf of the project, not to
  preserve the TC's (or Debian's) reputation among third parties who have no
  legitimate say in the outcome.

 At this point, it's blocking folks inside Debian, who are stakeholders.
 It's not just the trolls of reddit and the internet, it's DDs who are
 annoyed there's no decision and integration work isn't started. We're
 less than a year from freeze.

Annoyed, yes.  Blocked, no.  There has never been anything blocking any
Debian developer from doing work on improving the integration of systemd in
Debian, on their own packages or on the packages of others.  This has always
been possible, without making systemd the default at all.

If anyone *does* think they are blocked in doing this integration work
because the default has not been decided, that can only be because of a
misunderstanding of what deciding the default *means*.  And that is
precisely why I don't think it's good for the TC to send such an easily
misinterpreted message by deciding the default without addressing the
surrounding issues.

-- 
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: Both T and L are wrong, plea for something simpler

On Fri, Feb 7, 2014 at 5:37 PM, Paul Tagliamonte wrote:
 On Fri, Feb 07, 2014 at 02:27:25PM -0800, Steve Langasek wrote:
 So I don't think any
 maintainers should feel blocked on this by the lack of a formal vote; I
 certainly don't think that the conclusion of the vote is the only blocker
 for switching the default init system in jessie today [..]

 We really need to get a proper vote on this written on paper. We really
 do. It's the case where we need a direction and we need some body
 (frankly, at this point, it doesn't matter who) to say This is the init
 system for jessie on Linux

Prior to any change, the project should be assuming no change (i.e.
sysvinit).  Any inhibition on init system work is currently
self-imposed (excepting the logind issue).

The logind issue is legitimately blocking some progress, but that only
more clearly illustrates the fundamental problem.  That logind issue
is the one that needs referral to the TC, but no one has done that
yet.

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=MP1R5hHGnc1nH6kuMywLcSFQNN_AzHH2=ezky8gsqt...@mail.gmail.com

Bug#727708: Both T and L are wrong, plea for something simpler

Steve Langasek vor...@debian.org writes:

 I question the whole notion of DPL delegation of policy powers to the
 policy editors.  The power to decide the contents of the debian-policy
 package follows from their status as package maintainers; package
 maintenance is not something that I believe it's in the purview of the
 DPL to delegate.

This came up in the discussion over the delegation text.  I disagree with
this characterization of the Policy Editor role, and I think the other
Policy Editors also disagree.  I don't think we are just package
maintainers in the normal sense.  The debian-policy package is an artifact
of the process and a means for documenting its results, not the only
purpose of the group.

If debian-policy were merely a package like any other, then anyone else
who introduced a similar package into the archive would have the same role
within the project as the debian-policy package maintainers.  I don't
think this is how the project actually looks at the matter.  The Lintian
maintainers, the release team, the ftp-masters, and many other teams in
Debian take formal notice of the acts of the Policy Editors in a way that
wouldn't equally apply to some other package that people introduced into
the archive, and would continue to do so even if the results weren't
published as a Debian package.

 I'm not arguing that I don't think the policy editors are doing a good
 job - I'm grateful to them for the work they do.

I'm definitely *not* doing a good job as a Policy Editor at the moment,
but that's neither here nor there.  :)

 But constitutionally, I think the DPL doesn't have any authority to
 delegate the power to decide technical policy (which is a power reserved
 to the TC in the absence of consensus), only the power to act as
 recognized facilitators for policy discussions (i.e., the previous
 delegation that was in place).

This was basically the approach that I took in the delegation discussion,
and I still think it's basically correct.  The job of that role is to try
to document and coordinate discussions about the technical policy of the
project.  Formal decision-making in the event of a conflict rests with the
TC; the Policy Editor role is to try to dispose of the vast majority of
issues which do not require a formal discussion process or a vote.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87iospkwsd@windlord.stanford.edu

Re: Bug#727708: call for votes on default Linux init system for jessie

2014-02-08 Thread Paul Tagliamonte

On Sat, Feb 08, 2014 at 03:24:34PM -0800, Steve Langasek wrote:
  At this point, it's blocking folks inside Debian, who are stakeholders.
  It's not just the trolls of reddit and the internet, it's DDs who are
  annoyed there's no decision and integration work isn't started. We're
  less than a year from freeze.
 
 Annoyed, yes.  Blocked, no.  There has never been anything blocking any
 Debian developer from doing work on improving the integration of systemd in
 Debian, on their own packages or on the packages of others.  This has always
 been possible, without making systemd the default at all.

I understand you think that, and I empathize, but I disagree.

The fact is, I have limited time. If I'm going to focus on making a
bigger impact with my work, I'm going to stick to dealing with issues
that effect the most users.

I don't care about the init system all that much, in the end, it's not
important. I do care about ensuring we have something maintainable and
stable.

As soon as we settle which init system is default (and by a rough count,
I believe this issue is resolved now, thank you TC :) ), I can start
spending time on ensuring we have a polished distro throughout this
change by testing, and contributing patches when I hit issues that I
have time to fix.

I think this is the norm. I assure you it was not only annoying, but
also blocking.

 If anyone *does* think they are blocked in doing this integration work
 because the default has not been decided, that can only be because of a
 misunderstanding of what deciding the default *means*.

I don't grok. Default means it's going to be used by all users unless
they're technical enough to change it, in which case, I care slighly
less, since they're able to fix it and provide patches when they hit
issues.

 And that is
 precisely why I don't think it's good for the TC to send such an easily
 misinterpreted message by deciding the default without addressing the
 surrounding issues.

I understand why you might think that, but I believe it to not be
entirely in-line with how many view the situation.

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   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 default Linux init system for jessie

On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:
 Michael Gilbert writes:
 Why not hammer that out on -policy in public, and only if something goes
 wrong there, then defer it to the TC?

 Because -policy doesn't have a decision-making process other than
 consensus, so Ian's objections to all of the positions shy of L and my
 objections to L would deadlock and effectively block the -policy
 discussion from ever reaching a decision.  There is no method for either
 of us to be overridden.

But at least it would follow the usual process, and only when
consensus does actually fail does the TC need to mediate.

There would also presumably be proposed diffs to the policy text from
both sides for the TC to review, and decide among the options, and
that would be far more nuanced than this or that init as currently
proposed.

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=MOWM28M9k9Gx3oB-zMUpoMfYe7k=wbcvs9ubp1aw3r...@mail.gmail.com

Re: Bug#727708: call for votes on default Linux init system for jessie

Paul Tagliamonte paul...@debian.org writes:

 As soon as we settle which init system is default (and by a rough count,
 I believe this issue is resolved now, thank you TC :) )

It's not.  All ballot options have to have a majority above FD in order to
be eligible to win the ballot.  At least one more person has to vote
another option above FD for there to be a winner other than FD.

If all remaining TC members vote FD first, FD wins.  That would be the way
of indicating support for Ian's position that we should not hold
independent votes.

If all remaining TC members other than one vote FD first and the remaining
one votes something else first, that option wins, since our resolution
method fails later-no-harm spectacularly.  As Steve points out, all those
who have voted so far have voted in explicit disregard to this
possibility.  I did so on the grounds that I refuse to vote tactically at
that level, and it sounds like Steve is of a similar feeling.

FWIW, that's also why I want to vote the issues separately, since it
avoids a giant tactical morass.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87zjm1jhdh@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

2014-02-08 Thread Steven Chamberlain

On 08/02/14 23:24, Steve Langasek wrote:
 There has never been anything blocking any
 Debian developer from doing work on improving the integration of systemd in
 Debian, on their own packages or on the packages of others.

OTOH I'm eagerly awaiting the TC's decision[s] because it will likely
influence the direction of the non-Linux ports.

If Upstart had won somehow, most people working on GNU/kFreeBSD seemed
willing to adopt it on those grounds.  But it no longer seems the likely
choice for GNU/Linux.

And assuming systemd wins, a policy decision on dependencies and level
of coupling may lead to ports either supporting or dropping certain
packages, or a whole desktop environment.

IMHO it was a little frustrating that Ian's ballot couldn't go ahead
last week and reach a consensus on both issues.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



signature.asc
Description: OpenPGP digital signature

Bug#727708: call for votes on default Linux init system for jessie

Michael Gilbert mgilb...@debian.org writes:
 On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:

 Because -policy doesn't have a decision-making process other than
 consensus, so Ian's objections to all of the positions shy of L and my
 objections to L would deadlock and effectively block the -policy
 discussion from ever reaching a decision.  There is no method for
 either of us to be overridden.

 But at least it would follow the usual process, and only when
 consensus does actually fail does the TC need to mediate.

If you're looking for Policy Editors who enjoy running things through a
process that won't be successful just so that we can say they've been run
through a process, you're going to need someone other than me.  I find
that sort of thing to be tedious in the extreme and a giant waste of
everyone's time.  I have about four thousand things I could be working on
in Debian that would be more useful than going through that exercise.

 There would also presumably be proposed diffs to the policy text from
 both sides for the TC to review, and decide among the options, and
 that would be far more nuanced than this or that init as currently
 proposed.

I certainly hope that no one would spend lots of time drafting wording
without some broad agreement on what we wanted to say.  It's rare that the
question really rests on some point of minor nuance or phrasing; it's
better to hash out rough, broad statements until we get to some general
point of agreement and then work on diffs.  Otherwise, again, you run the
risk of wasting a bunch of people's time.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87txc9jh76@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:
 I understand you think that, and I empathize, but I disagree.

 The fact is, I have limited time. If I'm going to focus on making a
 bigger impact with my work, I'm going to stick to dealing with issues
 that effect the most users.

 I don't care about the init system all that much, in the end, it's not
 important. I do care about ensuring we have something maintainable and
 stable.

Why bring such a controversial and polarizing issue before the TC if
the outcome doesn't matter much to you?

sysvinit is maintainable and stable, so why seek to change it?

Paul, you know I think you're awesome, but you've stirred up a whole
lot of trouble here with a questionable motive.

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=MOLEPvgD_wFJN8ow3Ok_0JzvLaE=c7pskzpq+o8x5o...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

2014-02-08 Thread Cameron Norman

El Sat, 8 de Feb 2014 a las 3:56 PM, Michael Gilbert 
mgilb...@debian.org escribió:

On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:

 I understand you think that, and I empathize, but I disagree.

 The fact is, I have limited time. If I'm going to focus on making a
 bigger impact with my work, I'm going to stick to dealing with 
issues

 that effect the most users.

 I don't care about the init system all that much, in the end, it's 
not
 important. I do care about ensuring we have something maintainable 
and

 stable.


Why bring such a controversial and polarizing issue before the TC if
the outcome doesn't matter much to you?

sysvinit is maintainable and stable, so why seek to change it?



Perhaps the movement in GNOME to depend on a number of systemd provided 
interfaces has led Paul to believe that sysvinit is unmaintainable? 
AFAIR, systemd-shim was not available when he presented the question to 
the TC (or am I mistaken?).


--
Cameron

Bug#727708: Call for votes on init system resolution

2014-02-08 Thread Tollef Fog Heen

]] Adrian Bunk 

 On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote:
 ...
  I don't see any reason why,
  say, mountall or socklog-run should be required to support sysvinit.
 ...
 
 What about udev?

We will continue supporting udev at the current level for the jessie
release cycle.

Can you please find another dead horse to flog soon?

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


-- 
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/m27g953zc8@rahvafeir.err.no

Bug#727708: call for votes on default Linux init system for jessie

On Sat, Feb 8, 2014 at 7:17 PM, Russ Allbery wrote:
 Look, I've been involved in Policy work for years now.  I think I have a
 pretty good intuition for what sort of questions can be dealt with
 usefully in that framework and which ones can't.  You're certainly
 entitled to think that I'm wrong, but it's unlikely that I'm going to
 change my mind on this particular question, since I don't think it's even
 close.

 It's hard to avoid the feeling that you'd rather not have the TC discuss
 this question since the TC is arriving at a conclusion that you don't
 like.

It's not that I dislike any particular conclusion, it is that I
dislike the apparent rush toward conclusion.  The TC is a deliberative
body that is only supposed to act when all normal means have been
exhausted.  The fact that no policy discussion ever happened means
that something has really going wrong here.

I'd be happy to see a change post-jessie, but I feel like it is a
self-imposed rush to push anything through for jessie.

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=MPKyYmYGzxo6kFzkAZrA_-0=-7jnwpri9wuabvmbes...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

2014-02-08 Thread Tollef Fog Heen

]] Steve Langasek 

 Annoyed, yes.  Blocked, no.  There has never been anything blocking any
 Debian developer from doing work on improving the integration of systemd in
 Debian, on their own packages or on the packages of others.  This has always
 been possible, without making systemd the default at all.

It seems a bit pointless to start doing the work on how to change the
default to systemd until that was actually decided.  Once we have a
decision (and assuming that the default will be systemd), I was planning
on starting at looking at how to best do the transition.

So maybe not blocked as such, but «annoyed and unwilling to spend effort
that might be wasted».

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


-- 
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/m238jt3yoc@rahvafeir.err.no

Bug#727708: call for votes on default Linux init system for jessie