Bug#727708: multiple init systems - formal resolution proposal

Hi, Bdale Garbee: > I'm not comfortable with a mandate that packages may not require a > specific init system as pid 1. > Could we (or rather, the CTTE) compromise on "packages may mandate the default init system"? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-ctte-requ...@list

Bug#727708: Call for votes on init system resolution

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 w

Bug#727708: Call for votes on init system resolution

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

Bug#727708: Vote on Bdale's ballot plus GR

Why not just vote on Bdale's ballot plus the GR override provision? There are 4 members who apparently are going to rank systemd first with the GR provision, and Bdale casts the deciding vote, so systemd wins. Once systemd's victory and upstart's defeat is established, then discussion on everythi

Bug#727708: Call for votes on init system resolution

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 syste

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

Bug#727708: Steve Langasek Must Not Vote

Hello Ctte, I formerly request that Steve Langasek abstain from voting on this issue due to a clear conflict of interest: he is a top contributor to Upstart , and thus cannot make a clear-minded technical decision. This is compounded, of course,

Bug#727708: Please clarify L options with regard to interfaces

Hi. There seems to be a significant conflict within the TC about what the L options mean. Speaking as a maintainer who could be affected by this and as someone who would sponsor a GR to override one interpretation butnot another, I'd request that the TC clarify what it means with the next ballo

Bug#727708: Please clarify L options with regard to interfaces

Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"): > * Colin said that it would be OK to depend on a stable interface such as > logind-208 provided that multiple implementations could exist. Colin, I think you need to clarify this. I think it matters very mu

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.

Bug#727708: Call for votes on init system resolution

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

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

Bug#727708: [OFFLIST] - Possible trap to be avoided

Mike Bird writes ("[OFFLIST] - Possible trap to be avoided"): > > 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 > >

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

Bug#727708: [OFFLIST] - Possible trap to be avoided

Ian Jackson writes ("Bug#727708: [OFFLIST] - Possible trap to be avoided"): > Mike, I hope you won't mind me replying in public. > > You are entirely right. I intend to add a sentence saying "before the > release of jessie", which I think ought to be about the right time > limit. I have now done

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 draf

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

Bug#727708: init system decision timetable

I think we need to set a timetable and a process that we can adhere to, so that the process doesn't drag on indefinitely but so that no-one is caught by surprise. We have aborted this twice and I don't want to do it a third time. The solution to procedural cockup is additional formality. So, I t

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 pre

Bug#727708: init system formal proposal (round 3)

Ian Jackson writes ("Bug#727708: init system decision timetable"): > * Some TC member formally proposes some set of L options. This >should be the staunchest proponent of L, which I think is probably >me. That starts the constitutional discussion period. I therefore hereby propose the o

Bug#727708: Call for votes on init system resolution

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 miss

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 mysel

Bug#727708: Steve Langasek Must Not Vote

With all the due respect to Steve, considering the fact that he is a very involved contributor of Upstart and judging from his position on this subject, I also think he should step down from participating as a TC member in this specific issue. -- Lisandro Damián Nicanor Pérez Meyer http://per

Bug#727708: Steve Langasek Must Not Vote

On Fri, Feb 07, 2014 at 11:44:02AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > With all the due respect to Steve, considering the fact that he is a very > involved contributor of Upstart and judging from his position on this > subject, > I also think he should step down from participati

Bug#727708: Steve Langasek Must Vote

* Lisandro Damián Nicanor Pérez Meyer (lisan...@debian.org) wrote: > With all the due respect to Steve, considering the fact that he is a very > involved contributor of Upstart and judging from his position on this > subject, > I also think he should step down from participating as a TC member i

Bug#727708: Steve Langasek Must Not Vote

Lisandro Damián Nicanor Pérez Meyer writes ("Bug#727708: Steve Langasek Must Not Vote"): > With all the due respect to Steve, considering the fact that he is a very > involved contributor of Upstart and judging from his position on this > subject, > I also think he should step down from partici

Bug#727708: Steve Langasek Must Vote

Stephen Frost writes ("Bug#727708: Steve Langasek Must Vote"): > I don't agree with this. I have no reason to doubt Steve's ability to Please, also, no messages defending Steve's involvement. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe"

Re: Please restrict posting to #727708

On Thu, Feb 06, 2014 at 03:53:56PM +, Jonathan Wiltshire wrote: >Hi, > >Please give earnest consideration to limiting posting to #727708 >(the init system technical committee bug) to only those members of >the committee and whomever else they feel needs to contribute to >the discussion at this

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

Bug#727708: Please clarify L options with regard to interfaces

> "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well. Hmm, I am reading Ian as against 3. I request that TC members work with Ian on the wording of

Bug#727708: Please clarify L options with regard to interfaces

> "Sam" == Sam Hartman writes: > "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well. Sam> Hmm, I am reading Ian as against 3. I'm sorry, I

Re: Please restrict posting to #727708

Steve McIntyre writes ("Re: Please restrict posting to #727708"): > On Thu, Feb 06, 2014 at 03:53:56PM +, Jonathan Wiltshire wrote: > >Hi, > > > >Please give earnest consideration to limiting posting to #727708 > >(the init system technical committee bug) to only those members of > >the committ

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

Hi Kurt, Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit : > On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: > > I'm guessing that under you're asking for the interpretation of > > > > this in 6.1.1: > > | In each case the usual maintainer of the relevant software or > > | doc

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"): > I'm currently of the opinion that gnome made an initial decisions > and as reaction to that they are setting policy and that this will > be allowed under 6.1

Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]

Ian Jackson wrote: > Sam Hartman writes ("Bug#727708: Please clarify L options with regard to > interfaces"): >> I'm sorry, I missed the message that was a direct reply to me. >> >> I now understand Ian's position to mean that we must not require users >> to select a certain init system for thin

Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]

Paul Hedderly writes ("Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]"): > Ian Jackson wrote: > > Sam Hartman writes ("Bug#727708: Please clarify L options with regard to > > interfaces"): > >> I now understand Ian's position to mean that we must not require

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

On 02/07/2014 17:01, Ian Jackson wrote: > Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something > simpler (was: Re: Call for votes on init system resolution)"): >> I'm currently of the opinion that gnome made an initial decisions >> and as reaction to that they are setting po

Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade

At the risk of being yet another unhelpful member of the peanut gallery, I believe I see a way to resolve the impasse regarding the "T" and "L" options on the previous draft resolution. I'm not a DD but I have used unstable as my principal desktop OS since 1998, I've administered a handful of

Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]

Yeah, I now understand what you mean by L. I'll be writing more in the form of a blog post and probably GR text. I will send a pointer to the TC as I think I may be hitting close to something that Russ may find useful. I'll refrain from trying to convince the TC because you have enough voices t

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

On Fri, Feb 07, 2014 at 04:01:12PM +, Ian Jackson wrote: > Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something > simpler (was: Re: Call for votes on init system resolution)"): > > I'm currently of the opinion that gnome made an initial decisions > > and as reaction to t

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 02:04:42PM +, 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 optio

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

Le vendredi, 7 février 2014, 18.47:51 Kurt Roeckx a écrit : > > 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 th

Re: Please restrict posting to #727708

On Fri, 07 Feb 2014, Ian Jackson wrote: > Steve McIntyre writes ("Re: Please restrict posting to #727708"): > > On Thu, Feb 06, 2014 at 03:53:56PM +, Jonathan Wiltshire wrote: > > >Please give earnest consideration to limiting posting to #727708 > > >(the init system technical committee bug) to

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 01:08:46AM -0800, Keith Packard wrote: > 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 an

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

Steve Langasek writes: > On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote: >> If you decide on the init system question first, you could just file a >> bug against debian-policy and things could go their usual way. >> Alternatively, the Policy maintainers could defer this decision

Bug#727708: Call for votes on init system resolution

Hi, Russ Allbery writes: > Just to be very clear here, I do believe that we're deadlocked, even > though I expect the resolution process to be able to spit out a decision. > I don't mean deadlocked in the sense that Condorcet will fail, but rather > deadlock in the sense that the preferences abov

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

"Didier 'OdyX' Raboud" 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

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 10:42:13AM -0800, Russ Allbery wrote: > Andreas Barth writes: > > * Russ Allbery (r...@debian.org) [140207 02:09]: > > >> 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'

Bug#727708: Call for votes on init system resolution

Ansgar Burchardt writes: > Russ Allbery writes: >> Just to be very clear here, I do believe that we're deadlocked, even >> though I expect the resolution process to be able to spit out a >> decision. I don't mean deadlocked in the sense that Condorcet will >> fail, but rather deadlock in the se

Bug#727708: Please clarify L options with regard to interfaces

On Fri, Feb 07, 2014 at 01:44:42PM +, Ian Jackson wrote: > Sam Hartman writes ("Bug#727708: Please clarify L options with regard to > interfaces"): > > * Colin said that it would be OK to depend on a stable interface such as > > logind-208 provided that multiple implementations could exist.

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

On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote: > On 02/07/2014 17:01, Ian Jackson wrote: > > Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something > > simpler (was: Re: Call for votes on init system resolution)"): > >> I'm currently of the opinion that gnom

Bug#727708: Call for votes on init system resolution

Andreas Barth writes: > * Russ Allbery (r...@debian.org) [140207 02:09]: >> 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

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

On Fri, Feb 07, 2014 at 04:43:33PM +0100, Didier 'OdyX' Raboud wrote: > Hi Kurt, > > Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit : > > On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: > > > I'm guessing that under you're asking for the interpretation of > > > > > > this in

Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]

Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"): > Hmm, I am reading Ian as against 3. No, if there are multiple implementations then I am satisfied. In practice I don't think the problem of implementations only non-overlapping subsets of init systems will

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

Le vendredi, 7 février 2014, 11.04:12 Russ Allbery a écrit : > "Didier 'OdyX' Raboud" 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

Bug#727708: Call for votes on init system resolution

Hi Russ, On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote: > 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 importan

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

On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote: > "Didier 'OdyX' Raboud" 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 De

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

On Fri, Feb 07, 2014 at 07:44:31PM +0100, Ansgar Burchardt wrote: > Steve Langasek writes: > > On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote: > >> If you decide on the init system question first, you could just file a > >> bug against debian-policy and things could go their usua

Bug#727708: Call for votes on init system resolution

Quoting Cyril Brulebois (k...@debian.org): > 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. And, FWIW, though I *am* in some way following the -ctte list (including the giant #7

Re: Please restrict posting to #727708

Ian Jackson writes: > If so I think it would be useful, although I guess Bdale as chair of > the ctte ought to decide. I think it's far too late for it to be useful on our current issue. The bug thread is already too large to manage in any useful way. Bdale pgpByuzPqnFQt.pgp Description: PGP

Bug#727708: Call for votes on init system resolution

Steve Langasek 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 i

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

On Fri, 2014-02-07 at 13:22 -0800, Steve Langasek wrote: > On Fri, Feb 07, 2014 at 07:44:31PM +0100, Ansgar Burchardt wrote: > > Steve Langasek writes: > > > The Policy maintainers are the maintainers of the policy document, they > > > are > > > not "maintainers of the relevant software" in this

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

On Fri, Feb 07, 2014 at 10:05:47PM +0100, Didier 'OdyX' Raboud wrote: > I keep thinking that bundling the default init decision with ruling on > what software dependencies are allowed in Debian packs two quite > different issues, allows (or "features", one could say) tactical voting > and has,

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

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 [..]

Bug#727708: Additional CTTE Drafting Meeting useful?

Ian Jackson writes: > Ansgar Burchardt writes ("Re: Additional CTTE Drafting Meeting useful?"): >> In this case I suggest to decide just the question of the default init >> system on Linux architectures first and address further details later if >> no consensus can be found elsewhere. Finding the

Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade

On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote: > People have made various assertions about how difficult it would be to > port the necessary systemd components to run with some other init system, > or to create independent compatible implementations, but *no one has > actually done

Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade

Steve Langasek writes: > On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote: >> People have made various assertions about how difficult it would be to >> port the necessary systemd components to run with some other init >> system, or to create independent compatible implementations, bu

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

Hi, Steve Langasek writes: > Quite frankly, given that all members of the TC have by this point weighed > in with their preference on the "systemd vs. upstart" question and these > preferences can be tallied by hand, I don't think there should be any doubt > as to how the vote on that core questi

Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade

On Fri, Feb 7, 2014 at 5:39 PM, Steve Langasek wrote: > On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote: >> People have made various assertions about how difficult it would be to >> port the necessary systemd components to run with some other init system, >> or to create independent

Bug#727708: Call for votes on init system resolution

Keith Packard wrote: > I believe that votes cast in the last ballot demonstrate a unanimous > agreement that the answer for this package dependency question does not > in any way depend on which init system is the default, and so this > question could be resolved separately, with the question origi

Bug#727708: Call for votes on init system resolution

Colin Watson wrote: > 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 > t

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

Bug cc dropped, replaced with -ctte. On Fri, Feb 07, 2014 at 08:29:27AM +0200, Adrian Bunk wrote: > On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote: > > It's really pretty terrible to actively use FD to try to block options > > that aren't your favourite. > When you are saying "a set