Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Sorry for yet-another-mail on that (long-lasting) bug, but I feel it's important; so feel free to dismiss it if it isn't bringing to the conversation. Le jeudi, 6 février 2014, 16.27:15 Anthony Towns a écrit : 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 I'm quite puzzled by this (partial) result, generally ranking the L variants over the T's. I think letting any L variant win would create quite a precedent on what software is allowed in Debian. Software doesn't imply package and is loosely defined, the same goes for degraded operation. Is KDE a software, or are all of its independent parts softwares? Would failure to suspend under OpenRC be an acceptable degraded operation of the whole KDE or only of its upower/Solid/whatever component? L really reads to me like a way to enforce support for all init systems alike (thereby ensuring that the default init gets the same [bad] support) on maintainers and I feel it's too coercitive. On the other hand, T apparently brings in the fear of archive fragmentation by allowing the various init islands to develop on their own. Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort Now, I think this default init decision's purpose is to change the above agreement by replacing the syslinux in the above sentence by one of the contenders. Both the T and L riders purposedly don't say anything about the default init, and I think that's wrong: * T would permit islands outside of the default init (while I think that some prefer it because it allows the default init island to be technically sane) * L would enforce that any software can run on all inits (failure to work on one is equivalent to requiring any of the other ones, henc failing the requirement of L) The common agreement above stood until packages started to depend on systemd, which in the end, lead to the opening of this bug. I think the technical committee resolution on this issue should focus on outlining what the new deal should be, without stepping into defining what set of init systems the software shipped by Debian should or must support: the resolution should be limited to deciding what the new default init will be. Now, if there are concerns of eventual bad faith from the maintainers, the resolution could include something outlining the boundaries of the common agreement such as (which I think is the current consensus): All but specific packages are expected to work with the default init system. However, where feasible, packages should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. That (or any consensual phrasing along these lines) would completely replace both the T and L riders and be part of the resolution deciding which init system will be the default. I think that would vastly help making the decision largely understandable and consensual, where I'm afraid that any T or L variant would significantly unplease large sets of maintainers. Thanks for considering, cheers, Didier signature.asc Description: This is a digitally signed message part.
Bug#727708: Call for votes on init system resolution
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
Re: Additional CTTE Drafting Meeting useful?
Hi, On 02/06/2014 06:33, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Would one more IRC meeting be useful to nail down the ballot options and their drafts? I personally suspect that we have exhausted the capacity of the TC to deal with this problem, and that spending more time on it may actually result in worse decisions than we would make right now. Currently, I like each ballot we're getting less than I liked the previous one. So I'm dubious. Voting FD again due to failing to agree on a ballot might also indicate that the secondary question (allowing dependencies on functionality only available with a subset of existing init systems) have not been reasonably discussed elsewhere (as required by 6.3.5). 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 correct wording then should be easier. The init system vote could than have the options Bdale suggested earlier, with addition of a suitable GR override paragraph. The latter addition seemed at least uncontroversional except for a few wording issues. Chances are quite high that this will be decided by GR anyway at this point. In that case we could also just start the GR now. I don't think we win anything by delaying this decision further and further. In contrast, it will mean we will fix *less* integration bugs before the freeze if the init system changes. Ansgar -- 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/52f36793.6050...@debian.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: L really reads to me like a way to enforce support for all init systems alike (thereby ensuring that the default init gets the same [bad] support) on maintainers and I feel it's too coercitive. I don't interpret L as meaning that everything must support all init systems, certainly not alike (indeed the text of that option is explicit that it isn't necessarily alike). Rather, I interpret it as saying that software-outside-init must be flexible enough to cope with that possibility, and degrade sensibly to a lowest common subset of init system features (IOW in practice, needs to keep working if sysvinit is pid 1). Actual support for things beyond that minimum will require people who care about various init systems to step up and implement it. * L would enforce that any software can run on all inits (failure to work on one is equivalent to requiring any of the other ones, henc failing the requirement of L) That's not how I interpret it. A specific init system is in the singular. I'm not worried that we'll end up with cases where software-outside-init somehow manages to work with two init systems but not the others; working with more than one indicates the basic flexibility that I want to see, and the rest is up to developers who care about init systems. All but specific packages are expected to work with the default init system. However, where feasible, packages should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. Doesn't that just move the question to what the specific packages are, the scope of which is the core of the difference between T and L 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/20140206105005.ga15...@riva.ucam.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Colin Watson writes (Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)): On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: L really reads to me like a way to enforce support for all init systems alike (thereby ensuring that the default init gets the same [bad] support) on maintainers and I feel it's too coercitive. I don't interpret L as meaning that everything must support all init systems, certainly not alike (indeed the text of that option is explicit that it isn't necessarily alike). Rather, I interpret it as saying that software-outside-init must be flexible enough to cope with that possibility, and degrade sensibly to a lowest common subset of init system features (IOW in practice, needs to keep working if sysvinit is pid 1). Actual support for things beyond that minimum will require people who care about various init systems to step up and implement it. Precisely. 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.27196.910513.471...@chiark.greenend.org.uk
Bug#727708: Additional CTTE Drafting Meeting useful?
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 correct wording then should be easier. I strongly object to this approach for the reasons I have given already. If I am given the opportunity to do so, if such a resolution is proposed I will always propose amendments to settle the T vs L question. If I am not given the opportunity to do so, that would be because someone proposes a set of options which do not answer the tying question, and immediately calls for a vote. Under the circumstances that would be IMO a clear breach of process. I hope that now that I have made this perfectly clear, that this will not happen. 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.27136.274502.595...@chiark.greenend.org.uk
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: Both T and L are wrong, plea for something simpler
On Thu, Feb 06, 2014 at 12:05:05PM +0100, Ansgar Burchardt wrote: On 02/06/2014 11:50, Colin Watson wrote: I don't interpret L as meaning that everything must support all init systems, certainly not alike (indeed the text of that option is explicit that it isn't necessarily alike). Rather, I interpret it as saying that software-outside-init must be flexible enough to cope with that possibility, and degrade sensibly to a lowest common subset of init system features (IOW in practice, needs to keep working if sysvinit is pid 1). Actual support for things beyond that minimum will require people who care about various init systems to step up and implement it. What does this mean in the concrete example that lead to the ctte bug? That is: Provided logind is only provided by systemd (the current situation). May GNOME depend on logind? This is not quite the current situation. Neither systemd nor systemd-shim Provides: logind in the sense of the package relationship field right now, but both could do so. (In practice it looks as though it ought to be a virtual package name with an API version embedded in it; this is not a new or controversial technique elsewhere.) My interpretation of L is that GNOME may depend on logind (or logind-208 or whatever) as long as that dependency is declared such that another init system can provide it. I appreciate that there is the abstract question of what happens if no init system other than systemd actually steps up to do so; in practice I don't think this is a plausible outcome and so I don't plan to spend mental energy on it. My interpretation of T is that GNOME may depend directly on systemd or on related real packages, although it is encouraged to take some approach more like the above instead. -- 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/20140206111846.gd15...@riva.ucam.org
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
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: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Le jeudi, 6 février 2014, 10.50:05 Colin Watson a écrit : On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: L really reads to me like a way to enforce support for all init systems alike (thereby ensuring that the default init gets the same [bad] support) on maintainers and I feel it's too coercitive. I don't interpret L as meaning that everything must support all init systems, certainly not alike (indeed the text of that option is explicit that it isn't necessarily alike). Rather, I interpret it as saying that software-outside-init must be flexible enough to cope with that possibility, and degrade sensibly to a lowest common subset of init system features (IOW in practice, needs to keep working if sysvinit is pid 1). L doesn't say anything about lowest common subset, it says may not require a specific init system, which is different. * L would enforce that any software can run on all inits (failure to work on one is equivalent to requiring any of the other ones, henc failing the requirement of L) That's not how I interpret it. A specific init system is in the singular. In the case of interpreting L with specific init being singular, then a package requiring any of OpenRC and systemd would fit L as it doesn't require a specific init, but any within a set. If upstart would be taken as default, that's certainly not the intent of L, right? I'm not worried that we'll end up with cases where software-outside- init somehow manages to work with two init systems but not the others; working with more than one indicates the basic flexibility that I want to see, and the rest is up to developers who care about init systems. That's not what the L option says, again. Let's take logind as example (instead of inventing pseudo-test-cases). There are two views: * logind is considered part of systemd to be pid 1. L says you can't depend on any init being pid 1; L therefore imposes the maintainers of all software using logind to maintain interfaces to be working on non- systemd-inits (runtime-detection of [deprecated] ConsoleKit !?) * logind is not considered part of systemd to be pid 1 (the existence of a second implementation seems to suggest that), then software can depend on having logind available. How the logind interface is defined is mostly a matter of having maintainers of the various providers agree on virtual package names. That said, this view would make systemd- logind fall under L, imposing on its maintainers to make it work on non-systemd inits. I think L is putting the burden of maintenance wrongly in these two cases (on all consumers of logind or on the systemd-logind maintainers). All but specific packages are expected to work with the default init system. However, where feasible, packages should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. Doesn't that just move the question to what the specific packages are, the scope of which is the core of the difference between T and L anyway? Not in my view. It lets the individual maintainers decide whether their package is a sufficiently specific case. It also reinforces the role of the default init with regards to other non-defaults, explicitly ruling the init islands out. Any disagreement on the specificity can subsequently be referred to the TC, of course. What I tried to express in my earlier mail is that I think both T and L are simultaneously too vague and too specific: they both try to tell the Gnome maintainers (and others, of course) what they should or must do with regards to logind-being-tied-to-systemd, without explicitely writing it (too specific), while failing at making explicit that the default init should be supported (too vague). I also think they are both spelled in a way that assumes that maintainers would act in bad faith with regards to either upstart or systemd support in the cases where each wouldn't be taken as default. Finally, I have hard time seeing under which powers could L be decided by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there is no juridiction overlap that I could see (nor a disagreement about the matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul specifically asked for in 20131025184344.gb4...@helios.pault.ag: (…) 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) Paul's request is about a judgement call on where the efforts (…) shall go, not about setting technical policy. L, in its current state is too far-reaching in forbidding package relationships while the
Bug#727708: call for votes on default Linux init system for jessie
Josh Triplett writes (Bug#727708: call for votes on default Linux init system for jessie): That is a very interesting clarification, and not one that seems at all obvious from the text of 'L'. 'L' talks about Software outside of an init system's implementation, which does not seem like it would extend to management guis or addons. I think it depends what you think of as an init system's implementation. I would include the utilities you use to manage it. So, for instance, GNOME Logs, a new upstream project specifically designed to browse the systemd journal, could by the clarification above be considered part of the init system, and thus can depend on it? I haven't looked at that in detail. 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.32756.70574.623...@chiark.greenend.org.uk
Bug#727708: call for votes on default Linux init system for jessie
My first and last message to this list. To Those Who Understand --- Time ago, Linux was conceived as a Unix like OS. Thanks to internet it won acceptance between hackers familiarized with Unix, guys that liked and valued to have a Unix like OS at home. That first enthusiasm made Linux grow to the point some big companies put their eyes on it. Linux started to be popular and the dichotomy appeared. The big public has no interest in command line interface, the crowd has no interest in learning how to administering a Unix like OS and learn all that shell scripting. Read and write is annoying; welcome to modernity. What the crowd wants is fancy WYSIWYG friendly interfaces (even in server machines), like in Windows, what the crowd wants is fancy pop up notifications like in Windows, devices recognized and mounted on the fly like in Windows, a fancy full resolution image with a progress bar while booting, like in Windows. Well, big companies sell what the crowd buy, that's why they are big. The modifications made in the name of *modernity* (to give a Windows like OS to the crowd) that time ago just affected userland now took the base system, init system and the kernel. Like we all knew from the first time, finally the cancer took the whole body. Just the few that understand and value the idea behind Unix see the loss this means to everybody. But we are a minority, who cares? ;-) To Those Who Don't Understand - Do you think on another OS while using Linux? (does your wife think on another man while having sex with you?) Envy makes the world go round. All the spaghetti code you see on most big Linux distributions is not sysv-init fault. Any doubt? Give a try to Crux Linux (I mention Crux like an example, not propaganda), read its rc files and see how it boots and you won't want to hear about systemd/upstart tales anymore. That you don't want to read and write bash scripts? If you don't want to get your hands dirty why do you use FOSS? Walter -- 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/20140206131418.GA5062@lenovo.local
Bug#727708: Announcing sinit - the suckless init
Hi all, As part of experimenting with a toy distro I wanted to get rid of busybox's init, so I hacked together sinit[1]. sinit is based on Strake's init[2]. It is currently controlled via a FIFO. It supports only two commands (reboot and poweroff). It follows the classic style of config.def.h and it should work with any init scripts. I've been testing it with my init scripts[3]. Let me know what you guys think, I am looking forward to use this with sta.li. Thanks, sin [1] http://git.2f30.org/sinit [2] https://github.com/strake/init [3] http://git.2f30.org/fs/ -- 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/20140206123259.ga22...@destiny.2f30.org
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
Didier 'OdyX' Raboud dixit: Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort Eh, no! Debian is the universal OS, and it has quite a number of release architectures. And even then, including support for everything else is still strongly encouraged. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- 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.1402061419010.2...@herc.mirbsd.org
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
Re: Bug#727708: Call for votes on init system resolution
Colin Watson cjwat...@debian.org 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
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 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 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
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
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: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
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
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: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 01:30:25PM +0100, Didier 'OdyX' Raboud wrote: Finally, I have hard time seeing under which powers could L be decided by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there is no juridiction overlap that I could see (nor a disagreement about the matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul specifically asked for in 20131025184344.gb4...@helios.pault.ag: So Didier recently forwarded this to the secretary, saying: I've mailed Message-ID 1997214.E2693zAoXp@gyllingar to the init system bug, but forgot to CC you for a more binding advice on the constitutionality of L. I'm therefore hereby writing to you explicitely; my original message is attached. Don't hesitate to prove me wrong publically, I'm only interested in having a constitutionally sane decision out, rather sooner than later. I have also asked them under which power they decide things. This makes things so much clearer for everybody. The text from the last vote said: == dependencies rider version L (Loose coupling) == 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. 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 | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? I can certainly understand that that is one way of looking at it. I'm not yet sure about this and would like to receive some input. 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/20140206193825.ga8...@roeckx.be
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: 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.1. Yes, the T-vs-L thing is setting policy. (Although we're leaving the exact text of policy up to the policy editors.) 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.61398.394606.45...@chiark.greenend.org.uk
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: ... Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort sysvinit support was mandated indirectly due to it being the one and only init system used by Debian. But contrary to what you are saying, there is not one main Debian port that matters and all the others are just best effort. Now, I think this default init decision's purpose is to change the above agreement by replacing the syslinux in the above sentence by one of the contenders. Both the T and L riders purposedly don't say anything about the default init, and I think that's wrong: ... You might think that is wrong, but (like basically all possibilities) this has already been discussed here and none of the members of the TC seems to favor a must not require any init other than the default init so it didn't even make it to the TC ballot. In practice, L means that the old status quo that all packages have to work under sysvinit stays. And that also has benefits, e.g. it reduces the hassle for downstream distributions who use an init system other than the one Debian uses as default. There is not any right solution everyone could agree on, and after months of discussions it is extremely unlikely that someone expressing his opinion now could change the vote of any member of the TC. Thanks for considering, cheers, Didier 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/20140206203047.ga30...@bunk.dyndns.info
Bug#727708: Call for votes on init system resolution
On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote: On 7 February 2014 06:20, Ian Jackson ijack...@chiark.greenend.org.uk 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
Adrian Bunk b...@stusta.de 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) 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/87wqh7lw70@windlord.stanford.edu
Bug#727708: Call for votes on init system resolution
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
On 7 February 2014 08:44, Adrian Bunk b...@stusta.de 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 a...@erisian.com.au -- 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
Anthony Towns a...@erisian.com.au 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) 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/87fvnvlomo@windlord.stanford.edu
Bug#727708: I'd like to voice my opinion
I'd like to request that upstart be chosen over systemd mainly because there's already a large availability of deb packages that support init mainly due to ubuntu. Ubuntu acts as a gateway distro to the debian universe, and is a basis upon which numerous other distros are based as well. As such, a lot of packages are developed for ubuntu instead of debian. Making upstart the default init package allows for compatibility with the majority of these ubuntu specific packages. Furthermore, I know upstart is capable of maintaining backward compatibility with systemvinit scripts as debian implements them currently.
Bug#727708: I'd like to voice my opinion
El Thu, 6 de Feb 2014 a las 7:41 PM, Schlacta, Christ aarc...@aarcane.org escribió: I'd like to request that upstart be chosen over systemd mainly because there's already a large availability of deb packages that support init mainly due to ubuntu. Ubuntu acts as a gateway distro to the debian universe, and is a basis upon which numerous other distros are based as well. As such, a lot of packages are developed for ubuntu instead of debian. Making upstart the default init package allows for compatibility with the majority of these ubuntu specific packages. Furthermore, I know upstart is capable of maintaining backward compatibility with systemvinit scripts as debian implements them currently. Hello Christ. systemd proponents have been hard at work in getting systemd units packaged up and installed. Just load up Sid to see how many there are. Furthermore, systemd supports sysv scripts just like Upstart (actually, they are integrated into systemd's dependency chain, so the implementation is better in that way). I understand that you had the best of faith in writing this, but I assure you that the availability of init configurations will not be a problem for systemd, Upstart, or OpenRC (OpenRC supports sysv scripts). That said, Upstart could be a good choice because of the number of desktop environments that have their main focus as Ubuntu (Pantheon, Cinnamon, MATE) and could be encouraged to adopt Upstart as a session init if Debian goes with it. The same could be said of systemd, though (with GNOME and KDE instead of Pantheon and Cinnamon), though. Have a great day, Cameron
Bug#727708: Call for votes on init system resolution
Russ Allbery r...@debian.org writes: Don Armstrong d...@debian.org 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
Adrian Bunk b...@stusta.de 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
