Re: GR: Selecting the default init system for Debian
Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : Russ Allbery writes (Re: GR: Selecting the default init system for Debian): As a TC member, I dislike the supermajority requirement for the project to overturn a TC decision by GR, particularly in this case. I think we would all be extremely unhappy if the TC voted one way on the default init system and the project then voted a different way by a 60% majority. I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Cheers, OdyX [0] If §4.1.4 stood with something along the lines of unless the TC explicitly lowered that requirement, that would be different, of course. signature.asc Description: This is a digitally signed message part.
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 03:56:29PM +0100, Didier 'OdyX' Raboud wrote: I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). That would certainly seem to be the case, but it would be illogical for a group who is happy to be overridden with a lower requirement to be prevented from doing so! In practical terms, if the tech-ctte was so minded, they could use some of the proceedures in 4.2.2 to essentially achieve this outcome. Ian - any thoughts on if your tech-ctte constitution GR could address this? Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Neil McGovern writes (Re: GR: Selecting the default init system for Debian): That would certainly seem to be the case, but it would be illogical for a group who is happy to be overridden with a lower requirement to be prevented from doing so! Quite. I think it's perfectly possible for a TC resolution to make its meaning dependent on future facts. If X and Y, then A, otherwise B. It is also perfectly possible for a TC resolution to retract or modify a previous TC resolution. So all that's needed is for the TC to say all of our init system resolutions should be treated as withdrawn if contradicted by a simple majority in a GR. Ian - any thoughts on if your tech-ctte constitution GR could address this? You mean my TC resolution draft. Well, if you look at the debian-ctte list you will see that Bdale has decided to take matters into his own hands. He has proposed his own version of an init system resolution which lacks the GR override clause, without giving anyone a chance to comment on the text before calling for a vote. (I'm pretty cross with Bdale about that. Also he failed to send his messages to the bug, but only send them to the debian-ctte list.) I have proposed a separate TC resolution to try to address this, but it's obviously less clear. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21222.37685.301579.210...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 05:11:17PM +, Ian Jackson wrote: Ian - any thoughts on if your tech-ctte constitution GR could address this? You mean my TC resolution draft. Nope, I meant your supermajorty etc draft. Snipping the rest, as that seems to be something for tech-ctte, rather than me :) Neil -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127172208.gm8...@halon.org.uk
Re: GR: Selecting the default init system for Debian
Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ha8pl4re@windlord.stanford.edu
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 09:21:41AM -0800, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). Indeed, or at least to allow this to happen if tech-ctte wishes it. I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. So will I, but I believe it should be sufficiently clear at the moment to the developer body at large where the -ctte's view on this matter is. Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Neil McGovern writes (Re: GR: Selecting the default init system for Debian): On Mon, Jan 27, 2014 at 05:11:17PM +, Ian Jackson wrote: Ian - any thoughts on if your tech-ctte constitution GR could address this? You mean my TC resolution draft. Nope, I meant your supermajorty etc draft. Oh. I haven't done anything about that for a while of course. The init system thing has been keeping us busy. Snipping the rest, as that seems to be something for tech-ctte, rather than me :) OK, thanks. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21222.38854.689978.94...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 09:21:41AM -0800, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). I don't see why the TC wouldn't be able to vote for something again. Assuming there was a GR about it, this will most likely only be possible if the result of the GR was FD. I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. I guess this is most likely going to depend on how you word it. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127201432.ga16...@roeckx.be
Re: GR: Selecting the default init system for Debian
Russ Allbery r...@debian.org writes: Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. If you do this in advance, we get the chance for a nice infinite recursion if the outcome of the GR is to defer the decision to the TC. More popcorn! 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-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3dk27w8@vostro.rath.org
Re: GR: Selecting the default init system for Debian
On 19/01/14 03:25, Ben Hutchings wrote: In general, I've been quite unhappy with the excessive invocation of the TC recently, with developers seeming to view this as a first, rather than absolute last, resort. [...] Constitutionally, a GR is the last resort in that it can overrule every other decision. A GR can settle a decision finally but does *not* create consensus. So if you honestly think that more time should be allowed for a consensus to arise, perhaps you should propose a GR that says this issue is not ripe for the TC to decide on and sets some minimum delay before it can be brought to the TC again. It is not about the TC at all (unless they volunteer to do the work to implement any decision they make) Ultimately, whatever decision making process is used (GR, TC, etc) there needs to be some suggestion about who will actually do what and who presumably won't do anything or what will stop working E.g. if we choose systemd, who will implement all the things that need to be changed outside the Gnome related packages? What will immediately fail if not adapted to systemd? If we choose Upstart, it is not quite ready to do everything systemd would do and we have to trust the developers to follow through on their commitments to fill those gaps. I personally believe their intentions are good but promises are never the same as releases. If we decide to give them our trust and for any reason they can't deliver on time, what would we fall back on, is it enough to say we would just keep sysvinit for another 2 years, or would we defer the release and wait for them? Every option - and every fall back option - needs to be explained and accompanied by some details about who will do what if that option is chosen, if it hits a snag, etc. Only then do we have a list of choices for a GR -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52db97ff.8070...@pocock.com.au
Re: GR: Selecting the default init system for Debian
]] Daniel Pocock E.g. if we choose systemd, who will implement all the things that need to be changed outside the Gnome related packages? What will immediately fail if not adapted to systemd? In general, nothing should fail. sysvinit scripts are first class citizens in the systemd world and you can have native → sysv → native dependencies. There are some bugs, both in systemd and in init script (such as cycles), but in general this hasn't been a big problem so far. I believe that the ease of maintenance and the ability to do more with native systemd units (private /tmp, network namespacing, etc) will make it interesting for maintainers to move towards native units by themselves, but there's no flag day involved for a switch-over. So, I'm not sure what you mean by «all the things that need to be changed outside the GNOME related packages». If you have any particular things in mind, please feel to enumerate them and I'll answer to the best of my ability. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877g9ws2q0@xoog.err.no
Re: GR: Selecting the default init system for Debian
Guillem Jover writes (GR: Selecting the default init system for Debian): I think that forcing a decision through the TC at this time was very premature and inappropriate, [...] Perhaps surprisingly, I am not entirely opposed to the idea of a GR for this question. My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. Points that have be raised which are essentially political include: * What kinds of attitudes are appropriate in an upstream ? For example, how much is it reasonable for an upstream for a project to require a specific init system ? * How much do we as a project care about the non-Linux ports ? * How much do we care about desktop vs. non-desktop users ? * How much effort are we collectively willing to put into dealing with things that upstreams do that we find troublesome (implicitly, at the cost of spending time on other things) ? * How scared are we of ending up the effective upstream for projects of various sizes ? [1] * If we are worried about being dictated to by upstreams, which upstreams are more scary ? * Many of the considerations in your message are matters of Debian internal politics. These are all IMO reasonable questions that one might ask. I do think that the proper process is for the TC to make a decision at this stage. The way I read the constitution and the context is that it is the TC's job. Evidently you disagree. But there are certainly things that some TC members are suggesting which would lead me myself to want to propose or sponsor a GR to overturn it. If we are going to have a GR, we need of course to have all of the sensible options on the ballot. I think your division of the key possibilities is sensible. However, I think your option (B) needs further reconsideration. I doubt the project will have the appetite for two GRs on this topic. Most people are heartily sick of the subject already, probably. (Indeed I'm somewhat worried that people might want to punish the proposers and sponsors of a GR for prolonging such a tiresome dispute.) Thanks for your attention, Ian. [1] I don't mention the upstart CLA here because pretty much everyone agrees that the upstart CLA is ridiculous. The question is whether it is in fact a problem for us, which is a mixed technical and political question. It boils down to this: how difficult would it be to maintain it as a fork rather than a downstream (a technical question), and how likely it is that we will in practice end up with a patch stack which can't be resolved with upstream changes (a political question). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21211.48961.532515.291...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
I was going to write something longer about this, and I may still depending on whether I feel like I have a useful way to present the thoughts that are mingling in my head. But I wanted to at least briefly support Ian's point about a GR possibly being a more appropriate decision-making process if the decision hinges on political rather than technical grounds. I don't want to pass the buck, and there's a lot to be said for a small group of people doing a deep dive into an issue. But if this is more of a political question than a technical evaluation, the TC is in a very awkward place (unelected, basically self-selected, etc.) to be making political decisions for the project. Ian Jackson ijack...@chiark.greenend.org.uk writes: I do think that the proper process is for the TC to make a decision at this stage. The way I read the constitution and the context is that it is the TC's job. Evidently you disagree. But there are certainly things that some TC members are suggesting which would lead me myself to want to propose or sponsor a GR to overturn it. As a TC member, I dislike the supermajority requirement for the project to overturn a TC decision by GR, particularly in this case. I think we would all be extremely unhappy if the TC voted one way on the default init system and the project then voted a different way by a 60% majority. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4842mel@windlord.stanford.edu
Re: GR: Selecting the default init system for Debian
Russ Allbery writes (Re: GR: Selecting the default init system for Debian): Ian Jackson ijack...@chiark.greenend.org.uk writes: I do think that the proper process is for the TC to make a decision at this stage. The way I read the constitution and the context is that it is the TC's job. Evidently you disagree. But there are certainly things that some TC members are suggesting which would lead me myself to want to propose or sponsor a GR to overturn it. As a TC member, I dislike the supermajority requirement for the project to overturn a TC decision by GR, particularly in this case. I think we would all be extremely unhappy if the TC voted one way on the default init system and the project then voted a different way by a 60% majority. I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21211.51045.916717.913...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote: My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. I would gladly vote an option that says: technically, we trust what the TC says; politically, we are concerned about some of our upstreams' choices. A technical endorsement need not also be a political one. I would like to keep the technical and political issues as distinct as possible, though. I am not interested in spending time evaluating each option to form a technical opinion on what the best choice would be, and I'm extremely happy that the TC are doing that for me. I do have personal opinions on some of the upstreams' choices, but I believe that they should not get in the way of a technical decision. A constructive thing that we may do as a project to address the political side of the matter, is to add to our technical decision a list of things that we wish our upstreams would do to make all our lives easier in the future. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Enrico Zini writes (Re: GR: Selecting the default init system for Debian): A constructive thing that we may do as a project to address the political side of the matter, is to add to our technical decision a list of things that we wish our upstreams would do to make all our lives easier in the future. The main objections to some of the upstreams' behaviours are, basically, they don't care what anyone else thinks, and are trying to impose their will by various means. If that's the case, further imprecations aren't likely to make any difference. So the main political questions for Debian are (a) is this the case ? (b) does it matter ? (c) what are we going to do about it ? Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21211.61095.334496.108...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
Hi Guillem, I think you are missing the following options and have only listed options which you consider sensible or which you loath: h.) support them all equally: systemd, upstart, sysv and openrc and keep sysv as the default i.) support them all equally: systemd, upstart, sysv and openrc and make $foo1 the default j) support them all equally: systemd, upstart, sysv and openrc and make $foo2 the default k.) support them all equally: systemd, upstart, sysv and openrc and make $foo3 the default l.) accept the TC decision, whatever that will be m.) wait for the TC decision and then revote on this GR n.) wait for the TC decision and then start a new GR on this topic o.) my brain hurts, this is difficult, let's go shopping! p.) further discussion And, frankly, I'm disappointed by your *lousy* research on the topic (see both Tollefs and Steves reply), while at the same time I think you have given an *excellent* (bad) example, why voting is or can be bad: uninformed people vote on matters they dont fully understand. Given your lousy research I do assume you havent read the tech-ctte bug in question. If you had, I'm don't think you would think the same about the topic. (But then, most peoples minds aren't or cannot be changed by new information.) I do think this bug contains among of the best research of this topic. If you as a GR proposer cannot be bothered to inform yourself in the best possible way about it, I fear for a rather totally uninformed decision of other voters. cheers, Holger, who has come to the conclusion that this init system discussion is way more a bikeshed than what I would have assumed half a year ago. Indeed 99% of our users don't care and the majority of those who do care want their bikeshed their way or the highway... signature.asc Description: This is a digitally signed message part.
Re: GR: Selecting the default init system for Debian
Hi Holger, On Sun, Jan 19, 2014 at 04:53:12PM +0100, Holger Levsen wrote: o.) my brain hurts, this is difficult, let's go shopping! p.) further discussion p.) is rather I'd prefer fixing some bugs over voting and further discussion is q.) *excellent* (bad) example, why voting is or can be bad: uninformed people vote on matters they dont fully understand. +1 Holger, who has come to the conclusion that this init system discussion is way more a bikeshed than what I would have assumed half a year ago. Indeed 99% of our users don't care and the majority of those who do care want their bikeshed their way or the highway... While I agree in principle with all what you said before I think here is some distinction to bikesheding since the color of the bikeshed does not matter but the init system matters despite this attempt to put the decision on uninformed people (like me). But what I really wanted to say: Thanks for the nice MiniDebConf in Paris - it was a pleasure to be here. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119211255.gb13...@an3as.eu
Re: GR: Selecting the default init system for Debian
On Sun, 2014-01-19 at 01:01 +0100, Guillem Jover wrote: [ M-F-T set to debian-vote@l.d.o, not seeking sponsors yet see below. ] Hi! I think that forcing a decision through the TC at this time was very premature and inappropriate, because I don't think enough effort had been made to reach consensus (failing §6.3(6)), What would you consider to be enough effort? because the TC seems to have been trying to do design work (failing §6.3(5)), Did you also read the last sentence of that parargraph? and because even if they do have the power to decide on this (likely requiring a 3:1 majority in any case if they need to override the sysvinit maintainers, per §6.1(4)), The main change required to sysvinit would, I assume, be to remove the Essential flag. I do not think that use of the Essential flag is at the discretion of the package maintainer by default. I feel it's inappropriate for a small group of individuals to forcibly decide the global direction for the entire project. Important as the init system is, it does not 'decide the global direction for the entire project'. Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature, can have huge implications for what contributors or other Debian-based projects might have to work on, or stop working on. On the contrary, I think such decisions are precisely what the Technical Committee is for. [...] In general, I've been quite unhappy with the excessive invocation of the TC recently, with developers seeming to view this as a first, rather than absolute last, resort. [...] Constitutionally, a GR is the last resort in that it can overrule every other decision. A GR can settle a decision finally but does *not* create consensus. So if you honestly think that more time should be allowed for a consensus to arise, perhaps you should propose a GR that says this issue is not ripe for the TC to decide on and sets some minimum delay before it can be brought to the TC again. Ben, -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
