Re: [Proposal] GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 08:39:52PM +0100, Guillem Jover wrote: [ M-F-T and Reply-To set to debian-vote@l.d.o. ] Hi! This is the revised draft GR proposal (please see below); I'm looking for sponsors now. Since this or the other proposol failed to reach the needed amount of sponsors, the TC has made a decision and there wasn't any activity about this over 4 weeks I'm expiring this GR. You have 1 week to object to this. (This doesn't have anything to do with the one that was started by Matthew Vernon.) Kurt signature.asc Description: Digital signature
Re: Re: GR: Selecting the default init system for Debian
Matthew Vernon matt...@debian.org: My feeling at this stage is that the TC are best placed to make a decision on the technical merits of the various possible init replacements and how we might deploy them in Debian. Given that there is also a political element to this discussion, we could consider a GR in the light of the TC decision But what about more simple GR, just like the pool from: https://lists.debian.org/debian-ctte/2014/02/msg00281.html ? we could consider a GR in the light of the TC decision; pre-empting that decision would seem likely to result in a vast pile of duplicated flame/effort. The TC decision about the default init is done. But not about other important things, like requirements/suggestions for maintainers to support alternative inits and so on. I feel that if the GR results on the quoted above pool would be different from TC - that may affect other TC decisions. Ian, would you like to sponsor GR in this form? PS: BTW, Guillem what's a status of this GR-proposal? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215140612.ga13...@darkstar.order.hcn-strela.ru
Re: Re: GR: Selecting the default init system for Debian
On Sat, Feb 15, 2014 at 06:06:12PM +0400, Sergey B Kirpichev wrote: PS: BTW, Guillem what's a status of this GR-proposal? No seconds. Many objections. The TC has a decision. The flame is finally smoldering out. Can we move on as a project? Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Re: GR: Selecting the default init system for Debian
Hello, On Sat, Feb 15, 2014 at 7:21 PM, Paul Tagliamonte paul...@debian.orgwrote: On Sat, Feb 15, 2014 at 06:06:12PM +0400, Sergey B Kirpichev wrote: PS: BTW, Guillem what's a status of this GR-proposal? No seconds. Many objections. Sorry, I don't see this. Second proposal actually has sponsors, e.g.: https://lists.debian.org/debian-vote/2014/01/msg00054.html Cc'd Ian to clarify this assertion. The TC has a decision. But not a consensus on this question, they clearly see that GR makes sense. That's a part of their resolution: --8-- Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. --8-- The flame is finally smoldering out. Then please stop flamewars. Can we move on as a project? Of course. But please don't identify only yourself with the Debian project. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215154044.ga14...@darkstar.order.hcn-strela.ru
Re: Re: GR: Selecting the default init system for Debian
On Sat, February 15, 2014 15:06, Sergey B Kirpichev wrote: I feel that if the GR results on the quoted above pool would be different from TC - that may affect other TC decisions. Ian, would you like to sponsor GR in this form? PS: BTW, Guillem what's a status of this GR-proposal? With 1000 DD's there are more than enough people that can start a GR if they feel so. It seems strange to me that non-DD's need to be asking DD's on this list to please hold a vote amongst themselves. Thijs -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/400a4e9fc1448296cd15bf1dd336bc25.squir...@aphrodite.kinkhorst.nl
Re: OpenRC + Hurd status (was: [Proposal] GR: Selecting the default init system for Debian)
On 01/28/2014 11:44 PM, Thomas Goirand wrote: On 01/28/2014 03:39 AM, Guillem Jover wrote: Option D * Switch to sysvinit + OpenRC wherever available. - architectures where OpenRC is not currently available will switch whenever OpenRC has been ported, retaining their current default in the meantime. - a reimplementation of OpenRC, providing the same interfaces to the wider system, would satisfy the criteria above. I'm bothered by this phrasing. The wherever available doesn't sound appropriate to me. It doesn't even more now! :) I've also sent this to #727708, though it may be useful to write it here as well, if we finally go for a GR (option which I don't support btw). With the latest sysvinit package from Sid (eg: 2.88dsf-47) and the latest OpenRC package from Experimental (eg: 0.12.4+20131230-8), then Hurd just boots fine with OpenRC! :) Here's how to do it: apt-get install initscripts sysv-rc sysvinit \ sysvinit-core sysvinit-utils update-alternatives --config runsystem The later command tells hurd to use sysv-rc (otherwise it continues to use the Hurd specific boot hack thing...). Then just install OpenRC on top of that: apt-get install openrc I'm not sure installing sysv-rc is even needed. Probably installing OpenRC first, then the other sysvinit packages would work as well. There's nothing more to it: it just works (tm)! :) Hoping that the status update and our porting efforts are appreciated, Cheers, Thomas Goirand (zigo) P.S: My experience with Hurd was ok-ish, though the console randomly doesn't come up bug was really frustrating, especially considering that Hurd only uses ext2. :( -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f1f044.2070...@debian.org
Re: [Proposal] GR: Selecting the default init system for Debian
On Tue, Jan 28, 2014 at 11:44:58PM +0800, Thomas Goirand wrote: On 01/28/2014 03:39 AM, Guillem Jover wrote: Option D * Switch to sysvinit + OpenRC wherever available. - architectures where OpenRC is not currently available will switch whenever OpenRC has been ported, retaining their current default in the meantime. - a reimplementation of OpenRC, providing the same interfaces to the wider system, would satisfy the criteria above. For Hurd itself, it needs some fixes to be uploaded in sysvinit. It's not well known, but Hurd doesn't support *any* init system at all right now, it's only in the process of doing so. I wonder why it's taking so long to have the patches applied by the way (it's been waiting in the BTS since early September 2013). From my side, lack of any time in late 2013 and suffering from bad RSI for the last month. I'll not be doing much for the forseeable future due to the latter until things improve. Thankfully, this has been picked up and dealt with in the last week. Thanks to all involved for their efforts here. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202193942.gd11...@codelibre.net
Re: [Proposal] GR: Selecting the default init system for Debian
This one time, at band camp, Paul Tagliamonte said: I'd like to raise the objection that the TC hasn't done their job yet, and while the TC has done a great job of getting *true* technically grounded facts out yet, we've not let the process work. Let the TC do their work. They're coming up on a vote, and they may even suggest a GR. This GR is premature. Seconded. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: [Proposal] GR: Selecting the default init system for Debian
On Ma, 28 ian 14, 07:41:26, Charles Plessy wrote: Le Mon, Jan 27, 2014 at 08:39:52PM +0100, Guillem Jover a écrit : This is the revised draft GR proposal (please see below); I'm looking for sponsors now. Hi Guillem, if the result of the current TC vote is « further discussion », then I will second your GR. In the meantime, it is probably better to focus our thoughts on something else; it is only a matter of days now. According to the latest updates the TC vote is quite likely to end up with FD, but only because they want to redo the vote to allow a GR to override their decision with simple majority. Under these circumstances, why do you think it would still be a good idea to continue with the GR and not wait for the outcome of the real vote? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: [Proposal] GR: Selecting the default init system for Debian
Guillem Jover writes ([Proposal] GR: Selecting the default init system for Debian): This is the revised draft GR proposal (please see below); I'm looking for sponsors now. I would consider sponsoring a GR, but like others I would like to see the TC vote first. And, I strongly suggest you trim down both the number of options, and the length of the text for each option. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21223.46636.49434.780...@chiark.greenend.org.uk
Re: [Proposal] GR: Selecting the default init system for Debian
On 01/28/2014 03:39 AM, Guillem Jover wrote: Option D * Switch to sysvinit + OpenRC wherever available. - architectures where OpenRC is not currently available will switch whenever OpenRC has been ported, retaining their current default in the meantime. - a reimplementation of OpenRC, providing the same interfaces to the wider system, would satisfy the criteria above. I'm bothered by this phrasing. The wherever available doesn't sound appropriate to me. This shows that the writer didn't have all the information in his hands when writing this text. So I think I should explain what's the current status of OpenRC and ports. 1/ kFreeBSD For kFreeBSD, it just works (minus some warnings about stuff not being mounted very very early in the boot which we'd have to investigate, though it doesn't seem so bad and even impacting at all, and my virtualbox VM just boots fine...). 2/ Hurd For Hurd itself, it needs some fixes to be uploaded in sysvinit. It's not well known, but Hurd doesn't support *any* init system at all right now, it's only in the process of doing so. I wonder why it's taking so long to have the patches applied by the way (it's been waiting in the BTS since early September 2013). So Hurd *will* support sysv-rc OpenRC *soon* if someone decides to fix sysvinit. Though OpenRC in Hurd itself is ok already. See #721917 if you want to know more. Once that bug is fixed, then we just need #736636 to be solved (with the attached patch). Since #721917 is blocking, and that it's taking so long to have things to move, I'm not in such a hurry to have the new patch in #736636 uploaded (the bug committer just got his access on the new OpenRC project on Alioth and will do the work by himself). 3/ Conclusion So, all together, I think it's reasonable to say that *we do* have OpenRC support on all platforms, and that it's only a mater of closing a few RC bugs with attached patches (so, nothing blocking). Hoping that this will help others to understand better what's going on and know what we are at today. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e7d07a.3030...@debian.org
Re: GR: Selecting the default init system for Debian
On 01/23/2014 07:58 AM, Charles Plessy wrote: Perhaps the way out is to solve the technical problem regarding the Essential flag so that it is easier to install systemd, upstart or openrc, and defer a decision untill the call for change comes from enough maintainers of init scripts saying that they want to stop supporting it. Charles, Have you even TRIED OpenRC? There's no need to change any Essential flag in any Debian package to make it more easy to install... Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e7d969.3050...@debian.org
Re: [Proposal] GR: Selecting the default init system for Debian
Thomas Goirand z...@debian.org writes: Hoping that this will help others to understand better what's going on and know what we are at today. Thank you for the update, Thomas. Bdale pgpGP9stzQaFl.pgp Description: PGP signature
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-vote-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
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-vote-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
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-vote-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
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-vote-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
[Proposal] GR: Selecting the default init system for Debian
[ M-F-T and Reply-To set to debian-vote@l.d.o. ] Hi! This is the revised draft GR proposal (please see below); I'm looking for sponsors now. On Sun, 2014-01-19 at 01:01:44 +0100, Guillem Jover wrote: 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)), because the TC seems to have been trying to do design work (failing §6.3(5)), 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)), I feel it's inappropriate for a small group of individuals to forcibly 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. I feel that such decisions must belong to the project at large. Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. If they had done so, Debian could follow its usual organic and decentralized process, allowing the best solution for the project as a whole to emerge naturally through the consensus formed from the experience of these deployments. Instead, we have seen giant flamewars seemingly based largely on speculation, which have only made the situation worse by increasing acrimony within the project, with further polarization and antagonization between the different factions. IMO, forcing this issue via a small committee will not improve this in any way. 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. I think it's pernicious for the project to instill a regime of threats and force, that will almost always alienate at least one side of a dispute. It clearly denotes a dysfunctional project. It has even crossed my mind many times now, to propose a GR for each issue concerning project direction (if not all) escalated to the TC, or even propose a constitutional change to remove the TC's powers of coercion; restricting its rulings to be strictly advisory and non-binding, though I'm not sure this option would get wide traction amongst developers, if at all. I've been sitting back and trying to see the extent to which other developers support the view that the TC should not be deciding on issues of project direction; unfortunately, canvassing support from mailing lists is difficult, and handling a GR is quite a large undertaking, requiring a lot of time and energy, that others might not want or be able to invest, but would gladly get behind. So, with much reluctance and disappointment, I've finally caved and am considering proposing the following GR draft. Unfortunately nothing has changed up to this point; the TC is not backing off. I think the draft text should cover most of the options people seem to have expressed support for up to now. Note that it's not entirely clear how a _pending_ resolution by the TC would interact with a GR on the same, so I'd like input from the secretary before seeking support from sponsors, although to be honest I don't expect any problems here. As mentioned in the thread, if there's any issue with the above, the secretary can point it out during the discussion period if this gets support from enough sponsors. The two main changes are the addition of the explicit TC option, and the rewording of option B to not mention a GR explicitly, and to just postpone revisiting that decision to a later time. I chose that time to let some breathing after the jessie release, and because it's (usually) 1/3 of the non-frozen release time, so it would give enough room to deploy any possible changes before jessie+1. Attached is a diff against the original GR draft, for your convenience. ,--- DRAFT GR TEXT --- A General Resolution to select the default init system for Debian. Option A * Reinforce sysvinit and sysv-rc as the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option B * Changing the default init system is ultimately desirable, but premature at this point in time. - supporters of other init systems should continue their efforts towards full adoption by Debian through guidance in the policy manual, natural formation of consensus, and wider support through Debian packages by persuading maintainers to accept patches
Re: [Proposal] GR: Selecting the default init system for Debian
I'd like to raise the objection that the TC hasn't done their job yet, and while the TC has done a great job of getting *true* technically grounded facts out yet, we've not let the process work. Let the TC do their work. They're coming up on a vote, and they may even suggest a GR. This GR is premature. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [Proposal] GR: Selecting the default init system for Debian
Hi, Guillem Jover guil...@debian.org writes: ,--- DRAFT GR TEXT --- A General Resolution to select the default init system for Debian. Option A [...] Option H If people want to have a GR on the init system, could we please not entangle two issues in a single vote: 1. Default init system for jessie. 2. Init support in jessie+1. Also option C Defer the decision to the Technical Committee will be reduntant with another option once the TC makes a decision. I therefore suggest to wait until they made at least a decision on the default init on Linux[1]. Ansgar [1] Provided they don't explode before that. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761p5urjx@deep-thought.43-1.org
Re: [Proposal] GR: Selecting the default init system for Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 01/27/2014 08:39 PM, Guillem Jover wrote: This is the revised draft GR proposal (please see below); I'm looking for sponsors now. please stop wasting people's time and let the TC do their work instead. Thanks. - -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS5sJhAAoJEOs2Fxpv+UNfewsP/jxx7hOGao19Ol2Nn6S7lPf7 cWaOtztdKA9hl6hWzOQV0zjUetfGIepMwx44IK1XoXB1bq5aDwoeDln+Wiedwkgf 4XFWdE9pbZWmzS28obYnJeddF/S/aqKPX7L+aO9cV66Mg+I4GmZm1THMUPce0LfM ISA3Qge8MrhYijbmJ/SlaIMXJimdbYG3RXJE9BeCn3Nld7flSsnWGXRvoidt7pVV FrnH18mQrmYLibi13xQOY2i+zPH7Z/BV+xHsRXv+0hA50uhclamNoRW8Lszv3RjB GAsPO/H3XWN8qgKEkqRRCT6kbXbfTw2ezUOKPktu9tOF2qLmjzN8ri6mKg6lLCah DdeqEg5i+JsvSlywo/nyHNsiPyzP8mvMdb+C3TNMLYOY1xXZ7OWMN42dbsz66iEd dtTbmnoRSxhrPRZgqJgoPAvf/qkVj2WMciKEmN/qIPzlQcb4PJvthYIv9EYcdRTL cFg/sYC0ygEgwlXb45tnk6v5wm5PwGfiysDLZlT9ZL8zagIrtGrO4Q1kDwuNzisQ Xh1gQdoi7PByXJjb3c/picpvsih545/J+ziCmGM+2boCpeEudplxBc9txbsvPmlQ AkApsgS7Z+JP0kXNkOFr2qukZFtlZ1RUNC0KwopBJ7rXCeI0Jfibq1xl5FhteaDN /ZTdY2B1QsKm6NcWzbqL =Fvvl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e6c266.8060...@bzed.de
Re: [Proposal] GR: Selecting the default init system for Debian
Very much NOT seconded. I have way more interesting things to do than becoming an init system expert; and I would have to become one to be able to vote honestly in this GR. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127203635.ga9...@jwilk.net
Re: [Proposal] GR: Selecting the default init system for Debian
Le Mon, Jan 27, 2014 at 08:39:52PM +0100, Guillem Jover a écrit : This is the revised draft GR proposal (please see below); I'm looking for sponsors now. Hi Guillem, if the result of the current TC vote is « further discussion », then I will second your GR. In the meantime, it is probably better to focus our thoughts on something else; it is only a matter of days now. In the past, I have been alternatively on the side of proposing an impopular GR, and of strongly criticising another GR for its uselessness. My personal conclusion is that in doubt, a GR could contain an « rotten tomatoes » option such as: « this GR should not have been proposed », perhaps with a better wording. Can you consider that addition ? I will take my share of tomatoes if it turns out that the Project finds the option useful ! Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127224126.gb8...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit : On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. So, let me get this straight. Hi Wouter, OK, let's be straight :) You're saying let's do nothing until the entire system breaks because of a component that nobody really cares about, so that we can _then_ try to start a procedure which will take weeks (if not months) to maybe unbreak it, leaving the system in an utterly broken state in the meantime? What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. If some parts of the system become mutually exclusive, I do not see it as problematic. We do not support the co-installation of some mail or FTP servers packages even though in theory one can configure them to listen on different ports; if tomorrow one desktop manager depends on upstart and another on systemd, then the solution is to call this unsupported as well. I would also argue the same if it were web browsers. I would call a system broken if it would not be possible to do anything useful with any of the init systems. I do not see how this could happen. First, these init systems are developed and tested on computers that run them, such as Fedora, Ubuntu and Gentoo, which shows that there is no critical missing piece in one or the other system in the context where they are intended for. Second, at least systemd runs fine on Debian currently, and to my knowledge, there are no core components that are likely to drop systemd support in the near future. Then, there is the fear that because systemd or upstart is much easier to support than our current init system, the non-Linux architectures that can not run them will dissapear because init scripts will be dropped massively. To me it is a total overstatement. What is at stakes is whether these ports will benefit as much as before from the work on mainstream systems such as Linux on amd64. The answer with is “no”, unless we enforce a default with this goal in mind, that will cost to others what it gains to the non-Linux architectures. But that “no” does not make these projects impossible. At worse, it will force them to focus on their userbase instead of working on total coverage of the Debian package supermaket, and I think is would actually be a good change (please do not waste your time sending patches to leaf packages until you know that somebody is actually planning to use them on your port). Lastly, there is the political part. Should we boycott systemd or upstart ? Should we make choices that in practice mean to show the door to our GNOME team ? Should we push even more our contributors to participate to the porting on specialised architectures ? Let's releive the technical comittee from the pressure to step in that field. The best reaction to these questions is to ignore them. So definitely, thanks Steve and the sysinit maintainers for making transition between init systems easier; with this I do not think that we need a decision on a default system anymore. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125112035.gl24...@falafel.plessy.net
Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 08:20:35PM +0900, Charles Plessy wrote: Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit : On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. So, let me get this straight. Hi Wouter, OK, let's be straight :) You're saying let's do nothing until the entire system breaks because of a component that nobody really cares about, so that we can _then_ try to start a procedure which will take weeks (if not months) to maybe unbreak it, leaving the system in an utterly broken state in the meantime? What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. This argument has been brought up before (indeed, even by me), and has been debunked by several people. There are several problems with that approach for the choice of init system: First, a change of MTA, FTP server, or browser produces a user-visible change in an area that most users will care about. An init system does not--and note the most in the previous sentence. Second, it is possible to define the interface which an MTA, FTP server, or web server should provide to the rest of the system (e.g., serve files in this directory by default, or send mails to remote users if passed to the sendmail binary) without going into too much technical detail on how exactly the MTA, FTP daemon, or web server needs to do so, and also without sacrificing features that we might want. The same is not true for init systems. For instance, while we could just declare that all packages need to provide initscripts (which then means that even sysv-rc could still be used), that really is just the status quo, and we might as well not bother. I am personally convinced that we *do* need a better init system. I don't actually care _which_ init system that is, and am contend to leave that decision to the people who do. But we should not retain the status quo. If you think systemd will become the de facto default, then why not just throw out the years of bickering and bikeshedding and just decide that _now_? We should have made a decision on this subject years ago. The debate is reducing the quality of our mailing lists, is holding the entire project hostage, and we're *still* no closer to an answer. Even the TC seems to be having difficulties reaching a decision. So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. - I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that decision is the throw of a dice. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
Hi, On Samstag, 25. Januar 2014, Wouter Verhelst wrote: So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice.[...] - I am looking for seconds. And no, that's not a joke; Well, my option this is hard, my brain hurts, lets go shopping was a joke and essentially the same as the above. If you cannot wrap your mind around a problem, please dont declare defeat for the whole project or propose silly solutions. Just because the problem is too hard for some, doesnt mean there aint sensible solutions. Rolling a dice aint one of them. cheers, Holger P.S.: Also, btw unrelated: reasonable dices have 20 sides. Or 4 or 12. signature.asc Description: This is a digitally signed message part.
Re: GR: Selecting the default init system for Debian
Before I forget, there's one thing I wanted to say about this: On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: [...] Option A [...] Option B [...] Option C [...] Option D [...] Option E [...] Option F [...] Option G [...] Please don't do that. If you want to propose a GR, please only propose those options that you actually want to see win. When seconding, please only second those options that you actually want to see win (or lose against NOTA, so nobody will ever bring it up again). A ballot with too many options is never a good ballot, and no matter how hard you try you'll always miss one or two possibilities. That would mean we'd get a ballot with 8 or 9 options, which is too many in my opinion. When drafting a GR text for an option that you think is not the best option, the result will be that you'll end up with a text that those people who *do* think is the best option don't want to support. They'll not be willing to vote for or second those options then, or (worse) will try to propose their own amendment which is different, but only in small details--resulting in yet *another* option on the ballot. If enough people actually think some option in your list deserves being put on the ballot, rest assured they'll propose amendments and get them seconded. I have enough faith in our developers that this will happen. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 05:31:50PM +0100, Holger Levsen wrote: Hi, On Samstag, 25. Januar 2014, Wouter Verhelst wrote: So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice.[...] - I am looking for seconds. And no, that's not a joke; Well, my option this is hard, my brain hurts, lets go shopping was a joke and essentially the same as the above. If you cannot wrap your mind around a problem, please dont declare defeat for the whole project or propose silly solutions. Just because the problem is too hard for some, doesnt mean there aint sensible solutions. Rolling a dice aint one of them. I'm not saying that rolling a dice is the best option. But I *do* think it is a better option than 'further discussion', so if this ever gets to a vote I will most definitely rank this above NOTA. We need to make a decision on this subject. I'm still hoping the TC will be able to make that decision, but it remains possible that they don't. If that is the case, and this does come to a vote, I want to have this option on the ballot. Think of it as a last resort. I do want to go with the technically correct choice, if we as a project can make it. But if the technical committee fails to make a decision, and if a GR does the same, we'd end up with no decision. If given that option and rolling a dice, then I think rolling a dice is the lesser of the two evils. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
Hi! On Sat, 2014-01-25 at 17:06:45 +0100, Wouter Verhelst wrote: On Sat, Jan 25, 2014 at 08:20:35PM +0900, Charles Plessy wrote: What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. This argument has been brought up before (indeed, even by me), and has been debunked by several people. I very much disagree this argument has been debunked, I do accept other people have a different opinion on it though, but there's no point in discussin this here. I am personally convinced that we *do* need a better init system. I don't actually care _which_ init system that is, and am contend to leave that decision to the people who do. But we should not retain the status quo. We should have made a decision on this subject years ago. The debate is reducing the quality of our mailing lists, is holding the entire project hostage, and we're *still* no closer to an answer. Even the TC seems to be having difficulties reaching a decision. I was letting at least one week pass, to possibly get input from other people, or from the secretary, and I was/am planning on looking for sponsors on a revised GR draft tomorrow (including the defer to TC option and reworded Option B). If there's any conflict with the running TC resolution, the secretary can point it out before the vote, if enough people sponsor the GR, of course. So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. - I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that decision is the throw of a dice. Ok, given what you mentioned above, your preference is not easily represented with the current GR draft, and I don't think this amendment makes much sense (at least to me). You want a change, but don't care which; in which case I think it would be more appropriate to let the people who care decide, as you pointed out. I could see a decision by dice, being questioned as non-transparent, etc. But could see an option that essentially says (with better wording and all that): * Switch the init system to something else than sysvinit + sysv-rc. - a decision for a new init system needs to be made now, letting this undecided will keep causing frustration and project tension. - the init system chosen will be the one the project at large has a preference on, by selecting the winning option among options C-G. If something along those lines satisfies you, I'm happy to include a polished version in the GR draft. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125165047.ga27...@gaara.hadrons.org
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
Hi, On Samstag, 25. Januar 2014, Wouter Verhelst wrote: But if the technical committee fails to make a decision, and if a GR does the same, we'd end up with no decision. No. __If__ that happens, we'd end up with a decision keep the status quo, aka keep sysv as the default init system. That would be a valid decision. (And I don't understand why you didn't have it on your dice roll...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 05:50:47PM +0100, Guillem Jover wrote: On Sat, 2014-01-25 at 17:06:45 +0100, Wouter Verhelst wrote: [...] So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. - I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that decision is the throw of a dice. Ok, given what you mentioned above, your preference is not easily represented with the current GR draft, and I don't think this amendment makes much sense (at least to me). Well, that's of course your prerogative, but the fact that you came up with a long list of options doesn't negate my right to attempt to add another option, even if you think it doesn't belong there. You want a change, but don't care which; in which case I think it would be more appropriate to let the people who care decide, as you pointed out. That would of course be the best option, and I would be happy if we were to reach that. I could see a decision by dice, being questioned as non-transparent, etc. Hence the bit about two other DDs need to be present. I suppose we could possibly require a video recording. Alternatively, we could choose some factoid about the vote itself; like number of votes received modulo 3 decides the winner, or (all timestamps on all mails sent and received by devotee during the course of this vote represented in unix epoch, added together), modulo 3 decides the winner, or some other variation on that theme. The point is to essentially pull a decision out of thin air if all other attempts to make a decision failed. We need a decision. I don't care what that decision is, but we need one. Since a few months, this endless debate has reached the point where every thread on every mailinglist, given enough time, eventually turns into yet another instance of the init system debate. This is unhealthy for our community and needs to stop. But could see an option that essentially says (with better wording and all that): * Switch the init system to something else than sysvinit + sysv-rc. - a decision for a new init system needs to be made now, letting this undecided will keep causing frustration and project tension. - the init system chosen will be the one the project at large has a preference on, by selecting the winning option among options C-G. If something along those lines satisfies you, I'm happy to include a polished version in the GR draft. That would introduce interdependencies between votes, which has a serious risk of skewing the result (e.g., people would feel more compelled to rank one option lower, so that the chance of it winning indirectly through this option gets smaller; that would mean they wouldn't be expressing their actual opinion). I don't think that's a good idea. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 05:58:57PM +0100, Holger Levsen wrote: Hi, On Samstag, 25. Januar 2014, Wouter Verhelst wrote: But if the technical committee fails to make a decision, and if a GR does the same, we'd end up with no decision. No. __If__ that happens, we'd end up with a decision keep the status quo, aka keep sysv as the default init system. That would be a valid decision. (And I don't understand why you didn't have it on your dice roll...) Because I _have_ been convinced that we should replace sysv-rc by something else. I don't care what that something else is, but we need to do it. I'm also doubtful that if 'further discussion' wins this vote, the endless debate will end. Quite the contrary. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125173001.ge22...@grep.be
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, 2014-01-25 at 18:15:46 +0100, Wouter Verhelst wrote: On Sat, Jan 25, 2014 at 05:50:47PM +0100, Guillem Jover wrote: Ok, given what you mentioned above, your preference is not easily represented with the current GR draft, and I don't think this amendment makes much sense (at least to me). Well, that's of course your prerogative, but the fact that you came up with a long list of options doesn't negate my right to attempt to add another option, even if you think it doesn't belong there. Oh, absolutely, it just seemed a bit at odds with what you had just mentioned before. And in any case, I was trying to find an option or a vote solution that might satisfy your preference (which I've also seen elsewhere), and to avoid ending up with a monster ballot, with many options with very small variations over mostly the same. You want a change, but don't care which; in which case I think it would be more appropriate to let the people who care decide, as you pointed out. That would of course be the best option, and I would be happy if we were to reach that. I could see a decision by dice, being questioned as non-transparent, etc. Hence the bit about two other DDs need to be present. I suppose we could possibly require a video recording. Alternatively, we could choose some factoid about the vote itself; like number of votes received modulo 3 decides the winner, or (all timestamps on all mails sent and received by devotee during the course of this vote represented in unix epoch, added together), modulo 3 decides the winner, or some other variation on that theme. The point is to essentially pull a decision out of thin air if all other attempts to make a decision failed. Yes also considered the video, but still, what about the dices themselves, etc; the other options you mention are a bit better. But in any case I don't think it's a good idea, really, it would probably piss off anyone who cares about a specific choice, and people would keep challenging the vote, becuse it was random. Obviously if you still think it is a good idea and others agree, then it will end up being included. We need a decision. I don't care what that decision is, but we need one. Since a few months, this endless debate has reached the point where every thread on every mailinglist, given enough time, eventually turns into yet another instance of the init system debate. This is unhealthy for our community and needs to stop. Well, I think a vote by the project, whatever the outcome (status quo, postpone, specific option), will be a clear message that people would stop going on about it (at least for a while :). But could see an option that essentially says (with better wording and all that): * Switch the init system to something else than sysvinit + sysv-rc. - a decision for a new init system needs to be made now, letting this undecided will keep causing frustration and project tension. - the init system chosen will be the one the project at large has a preference on, by selecting the winning option among options C-G. If something along those lines satisfies you, I'm happy to include a polished version in the GR draft. That would introduce interdependencies between votes, which has a serious risk of skewing the result (e.g., people would feel more compelled to rank one option lower, so that the chance of it winning indirectly through this option gets smaller; that would mean they wouldn't be expressing their actual opinion). I don't think that's a good idea. Actually I agree, because I just realized your preference (I think) can actually be represented with the current ballot. You could rank all options that specify a change from the current default above NOTA, and the reset below. If you (as in the generic voter), really don't care can rank all options above NOTA equally. Given this I'm not planning on adding such option. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125212413.ga31...@pulsar.hadrons.org
Re: GR: Selecting the default init system for Debian
Le Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover a écrit : 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)) Hi Guillem, I agree that calling the TC was premature. We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. In my understanding, to have GNOME 3.10 in Debian, we need to work around this difficulty. As a consequence, this would pull systemd on such a large number of systems, but as long as GNOME needs to explicitely depend on it, it is still not the default. I have not read GNOME or systemd packagers asking to the maintainers of packages containing init scripts to drop support for our current default system. The Debian way of doing things is that if a systemd service file is missing, a patch should be sent. If the TC choses a new default that is not systemd, the situation of GNOME does not change: it will still need a mechanism to pull systemd and replace the default. But at the time the TC was called, I was not under the impression that the GNOME or systemd maintainers have asked for a decision, and I very much agree with that: first, one has to show in Testing a system where GNOME and systemd work well. In that sense, the call to the TC was premature: we should remove obstacles for change, and only top-down decide when some ways are incompatible in a way that is affecting a large number of users. If one day it is not possible to have Desktop manager A and Desktop manager B installed on the same machine, the solution may be simply to call this unsupported unless there is a significant demand for this feature. Perhaps the way out is to solve the technical problem regarding the Essential flag so that it is easier to install systemd, upstart or openrc, and defer a decision untill the call for change comes from enough maintainers of init scripts saying that they want to stop supporting it. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122235808.gc12...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
On Thu, Jan 23, 2014 at 08:58:08AM +0900, Charles Plessy wrote: Le Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover a écrit : 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)) I agree that calling the TC was premature. We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. Factually incorrect. The sysvinit package in unstable has been fixed to depend on sysvinit-core | upstart | systemd-sysv, allowing users to switch between init systems without removing an essential package. In my understanding, to have GNOME 3.10 in Debian, we need to work around this difficulty. Not true, on multiple axes. In that sense, the call to the TC was premature: we should remove obstacles for change, and only top-down decide when some ways are incompatible in a way that is affecting a large number of users. If one day it is not possible to have Desktop manager A and Desktop manager B installed on the same machine, the solution may be simply to call this unsupported unless there is a significant demand for this feature. A decision needs to be made about the default init system. Like other questions of defaults, it's not clearly the remit of any particular maintainer or maintenance team in Debian. Such things tend to be decided by fiat by the installer team, but in this case that's not possible; the presence of the Essential flag on the sysvinit package historically means that the change of default must be made by coordination with the sysvinit maintainers. If you want to avoid a TC decision, I suppose that as a regular committer to the sysvinit package I could just take it upon myself to set upstart as the default. But I thought that it might be better to have a slightly less unilateral decision-making approach. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Le Wed, Jan 22, 2014 at 04:26:16PM -0800, Steve Langasek a écrit : On Thu, Jan 23, 2014 at 08:58:08AM +0900, Charles Plessy wrote: We have a default init system that has the Essential flag, and it is impossible to switch to alternatives without going through a very strong warning. Factually incorrect. The sysvinit package in unstable has been fixed to depend on sysvinit-core | upstart | systemd-sysv, allowing users to switch between init systems without removing an essential package. Thanks for the clarification. An earlier message in this thread gave me the impression that it still had been the case (that I went through when installing systemd on my machines), but indeed I was wrong. In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140123005814.gd12...@falafel.plessy.net
Re: GR: Selecting the default init system for Debian
On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. So, let me get this straight. You're saying let's do nothing until the entire system breaks because of a component that nobody really cares about, so that we can _then_ try to start a procedure which will take weeks (if not months) to maybe unbreak it, leaving the system in an utterly broken state in the meantime? I seriously question that logic. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140123031441.gf18...@grep.be
Re: GR: Selecting the default init system for Debian
[ Given the tone in this mail, I'd usually not bother replying, but I guess it's my duty given the proposed changes to the draft. ] Hi, On Sun, 2014-01-19 at 16:53:12 +0100, Holger Levsen wrote: I think you are missing the following options and have only listed options which you consider sensible or which you loath: I'd have guessed it'd be obvious why I might not include options I consider inappropriate or insane? People can always propose amendments for those. Of course, that does not mean I might have missed other good options people might favour. 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 I'd actually love if the project could support all init systems equally, and not even these, all the ones that have not been proposed like runit, minit, etc. I'm actually an idealist, but in a voluntary project like Debian, there's a point where ones ideals must not take precedence, when confronted with ideas that might imply making others to do things they don't want which I find totally inappropriate; this is a maxim I've tried to follow when drafting the GR. For example I think it would be totally uncalled for, to force the systemd maintainers to carry portability patches (if those ever happen) when their upstream and themselves have stated that would make them very unhappy, when other people could instead fork systemd or reimplement their interfaces (and this is talking as a porter). Unfortunately I think supporting all these equally is very much unfeasible, and would put a huge burden on maintainers. One thing is for a maintainer preferring init system X, while the default is Y, to support both natively, the other is requiring them to test and run all these different init systems on each upload, either through VMs, dedicated hosts, or init system package switches. We do not require of maintainers that they support themselves all our architectures, and we don't even consider it a serious bug if a package has never been built for one (be it Linux-based or not, mind you), the same should apply to init systems IMO. So in these cases I consider they are already covered in spirit by the non-exclusive options in the draft. 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 See my reply to Enrico. 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... I'm actually flabbergasted at how you've reached that conclusion, given that I've tried very hard to not imprint any judgment on any given init sytem, on purpose, so to avoid having the GR proposal itself turn into a monster rehash of the same. Personally, I do actually trust my fellow project members to get properly informed themselves by the time of a vote, seeking help/advice/inspiration from others, not voting if they don't care at all what the project decides, etc. On one hand I don't think I should be dignifying this with a reply, on the other not clarifying might possibly cloud the impression or lack thereof of due process when drafting the GR itself. I'd also rather not be talking about my credentials, or lack thereof, TBH, I'd have happily replied in private if asked nicely. I'd rather talk just about the merits or lack thereof of the options in the GR draft itself. In any case, given the character assassination above, here's my involvement in this issue, trying to keep any possible judgment for any particular init system out of it, because my preference, really, would be for the project at large to reach consensus on the issue: * While at Nokia, was involved in the
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-vote-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-vote-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
On 13461 March 1977, Guillem Jover wrote: I think that forcing a decision through the TC at this time was very premature and inappropriate Quite the contrary, it was the right thing to do. This issue will not get any easier or more clearcut the longer we let it wait and see if maybe the maintainers will get to a consensus. They won't, this much has been clear from the beginning, the systems are simply way too different for that to happen. So it was the right time (or maybe even a bit late) to ask the TC to take this decision. I feel it's inappropriate for a small group of individuals to forcibly 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. I feel that such decisions must belong to the project at large. Where do they decide the global direction for the project? They have a technical decision to do. Sure it has a wide impact, but global direction is something different than just an init thingie. Also, seeing how much involvement we have in votes usually, I am far more happy to have a small group of people invest a lot of time to get to know all the various edges of all the involved systems and making an informed decision based on that, giving us long reasonings WHY they decided the way they did, than having a vote where a few hundred CAN vote, way less than that usually DO vote, and even less really inform themself of WHAT they vote on. Sure, there may be some who go long ways to get all the details, but I could bet their number is SMALL, especially if you look at, eg., how deep TC members like Russ went into the issue. The quality of the decision will be much better with the CTTE. -- bye, Joerg I. What would you do if a package has no sane default configuration? (There is *no* default configuration that works on most systems!) The best thing to do would be to add such a default configuration. [... ARGS ...] signature.asc Description: PGP signature
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-vote-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-vote-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-vote-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
Hi, dropping the useless cc: and not commenting on the thread topic at all so far yet... On Sonntag, 19. Januar 2014, Ian Jackson wrote: As a TC member, I dislike the supermajority requirement for the project to overturn a TC decision by GR, particularly in this case. I agree. I think that would be quite bad. care to explain why you think so? I do think its a useful requirement to avoid $adjective GRs like this one (or at least make them harder). cheers, Holger signature.asc Description: This is a digitally signed message part.
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-vote-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 Steve! On Sat, 2014-01-18 at 19:16:44 -0800, Steve Langasek wrote: On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. […] can I ask how you arrived at the conclusion that not much energy has been expended on upstart in Debian? I've actually spent quite a lot of time and energy on getting upstart, and other base system packages, into a state that users should be able to switch from sysvinit to upstart without regressions. That means getting the ifupdown integration in place, making sure lvm and network filesystems work at boot, ensuring transparent handling of startpar dependencies on scripts that are shadowed by native upstart jobs, etc. Sorry, that wording was probably unclear. I *do* know you have done lots of work on upstart in Debian, that's why I also included the point about the policy update. But here I didn't mention, on purpose, work done on specific init systems themselves, helpers and immediate surroundings, but on wide deployment. I didn't mean to devalue the work you and other upstart supporters have done (or other init system alternative supporters for that matter), I'm sorry that might have been your impression. It does *not* mean doing very much work on pushing native upstart jobs to maintainers of leaf packages; that should be secondary to getting a complete and correct base into Debian. But we certainly are at the point today where such jobs can be implemented more widely in packages. If you have a different standard for seeking wide deployment, I'm interested to know what it is. Well, for example, only just very recently it got to a point where upstart could be installed w/o scary essential removal prompts and similar (again, work that you did). And yes, when I mentioned seeking wide deployment, I meant archive wide support. Let me try to give an analogy to clarify what I mean. Say, the GNU/kFooBar porters might have invested lots of effort into their kernel, toolchain and kFooBar-specific utilities, which in addition might be in excellent shape; but if the architecture only has 10% packages built for that port, and they stop there, then it cannot get exposure of its possible features, advantages or different ways to do things, and people interested in particular packages might not see the point in even giving it a try. Expecting the project at large to do the other 90% of the porting seems unrelalistic, even if the system has a very solid foundation, because at this point it might not show much advantage to the current ones. Instead I think the work that many porters have done, by sending patches to port packages to their systems, have in many cases triggered curiosity to the point of people possibly experimenting with those ports, or at least seeing value in supporting these even by themselves. There's probably many other similar examples, like having excellent cross-building support in the toolchain but having no actual cross-buildable package in the archive, etc. In the upstart case, most of the work could have been reused from Ubuntu, w/o interfering with the current init system default. I seem to understand reluctance to push native upstart jobs into Debian was partially out of respect towards the project. I just think that respect was misplaced for something that was optional, and it actually backfired. Hope that clarifies. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119163246.ga4...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
On Sun, Jan 19, 2014 at 05:32:46PM +0100, Guillem Jover wrote: And yes, when I mentioned seeking wide deployment, I meant archive wide support. Let me try to give an analogy to clarify what I mean. Say, the GNU/kFooBar porters might have invested lots of effort into their kernel, toolchain and kFooBar-specific utilities, which in addition might be in excellent shape; but if the architecture only has 10% packages built for that port, and they stop there, then it cannot get exposure of its possible features, advantages or different ways to do things, and people interested in particular packages might not see the point in even giving it a try. Expecting the project at large to do the other 90% of the porting seems unrelalistic, even if the system has a very solid foundation, because at this point it might not show much advantage to the current ones. Sure. This isn't the init system debate, though. Each init system can 100% boot the system and expose features. You can try to say this is the other ports (HURD), but I don't think you're seriously asserting that HURD is 90% of Debian. Instead I think the work that many porters have done, by sending patches to port packages to their systems, have in many cases triggered curiosity to the point of people possibly experimenting with those ports, or at least seeing value in supporting these even by themselves. There's probably many other similar examples, like having excellent cross-building support in the toolchain but having no actual cross-buildable package in the archive, etc. I don't grok what this has to do with init systems. Are you saying they're broken? In the upstart case, most of the work could have been reused from Ubuntu, w/o interfering with the current init system default. I seem to understand reluctance to push native upstart jobs into Debian was partially out of respect towards the project. I just think that respect was misplaced for something that was optional, and it actually backfired. You do know upstart can use standard init scripts, yeah? Hope that clarifies. Alas, not for me. Thanks, Guillem Much love, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Joerg Jaspert dijo [Sun, Jan 19, 2014 at 11:36:25AM +0100]: Where do they decide the global direction for the project? They have a technical decision to do. Sure it has a wide impact, but global direction is something different than just an init thingie. Also, seeing how much involvement we have in votes usually, I am far more happy to have a small group of people invest a lot of time to get to know all the various edges of all the involved systems and making an informed decision based on that, giving us long reasonings WHY they decided the way they did, than having a vote where a few hundred CAN vote, way less than that usually DO vote, and even less really inform themself of WHAT they vote on. Sure, there may be some who go long ways to get all the details, but I could bet their number is SMALL, especially if you look at, eg., how deep TC members like Russ went into the issue. The quality of the decision will be much better with the CTTE. I doubt I can state my opinion in a clearer way than what Ganeff has stated here. I'm completely with him — No good will come from rehashing the argument in a project-wide fashion once again. signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Holger Levsen hol...@layer-acht.org writes: On Sonntag, 19. Januar 2014, Ian Jackson wrote: As a TC member, I dislike the supermajority requirement for the project to overturn a TC decision by GR, particularly in this case. I agree. I think that would be quite bad. care to explain why you think so? I do think its a useful requirement to avoid $adjective GRs like this one (or at least make them harder). Supporting a new init system is going to be a group effort by large portions of the project, and is going to have substantial impact on a lot of work inside Debian (non-Linux ports, desktop environments, udev maintenance, convergence or lack thereof with Ubuntu, and so on). If the project at large is actually opposed to whatever decision the TC makes, I think it will be very difficult on a practical level for that decision to be effective. (Note that assumes opposition, not I would have chosen differently, but this is fine.) And, more generally, I feel like we should be careful about how much legitimacy the TC has. It's an unelected and basically self-selected group of people, and in that situation, it's quite possible for the TC to diverge from the goals of the rest of the project and not realize it. This is something that I think we can manage, particularly given that the TC members are aware of this and are trying to take it into account, but, well, one of the great features of Debian for me is that other people don't tell me what to do. And of course it's unsurprising that I, as a TC member, think we can manage that; my opinion isn't the one that matters. The TC must not become akin to the typical management structure of a corporation, able to make unaccountable decisions and impose them on the workers. It would destroy one of the major features of Debian as aproject. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u03kbmh@windlord.stanford.edu
Re: GR: Selecting the default init system for Debian
Hi Ian! On Sun, 2014-01-19 at 12:04:17 +, Ian Jackson wrote: 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. Actually, no, part of my reasons include several of the ones you list, as I tried to imply when writting “Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature,”. I should probably have been more explicit (seems to be a common fault of mine :/ ), but didn't want to go into specific details for those, I guess that was a mistake. :) For example with strategic, I was thinking about things like: * Does the project want to align itself with an existing ecosystem or distribution? - Due to similarities and existing relationships with other projects. - Or due to perceived number of supporting distributions. - Or due to perceived global userbase. * Maybe even to try to tip the scale one way or another; either to counterweight what might be perceived as having more support by the rest of the community so that diversity is preserved, or to try to standardize on a global one so that the others can wane off, eventually? For political, several of the ones you've listed, and of a subjective design nature things like: * Being more or less portable, allowing to use the full extent of a system, or providing a common baseline for many systems creating uniformity. * Being more user extensible, or having no knobs and trying to have only good defaults. * Being tightly coupled or allowing for parts to be easily replaced. * Shifting the complexity from system to the users (users here would be daemons), or the other way around (implementation and interfaces wise). * Incremental evolution of existing systems or revolutionary new systems. * etc. which in the end are all possible valid design philosophies, with different tradeoffs, depending on the context, usage, expectations, etc. Where reasonable people can have opposite opinions or preferences. A really good characterization of what I mean could be the New Jersey vs MIT schools of thought, as represented in the well known The Rise of Worse is Better writup. http://dreamsongs.com/RiseOfWorseIsBetter.html 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 the TC was to continue making the decision, I'd want to run the GR regardless of the outcome, even if I'd agree with it; althought as I've mentioned before I find the 2:1 majority unfair. 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. Thanks. However, I think your option (B) needs further reconsideration. I doubt the project will have the appetite for two GRs on this topic. Well, I'd rather not be spending time in the current GR either, I'd prefer to be doing something else instead, to be honest. But regarding option B, I'd also very strongly prefer if no other GR would appear, but I know that some people are eager to get a decision made and be done with it (even if it would get postponed now), and will not want to wait either, so that was more of a compromise than anything else. 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.) (In a way I guess I accepted that burden when I offered myself as a sacrificial token.) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119193601.gb4...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
Holger Levsen writes (Re: GR: Selecting the default init system for Debian): care to explain why you think so? Russ has given an answer which I agree with. But more fundamentally for me: if the project as a whole votes to overrule the TC on this question, but by a constitutionally insufficient margin, then I worry that the TC's decision would lack political legitimacy within the project. That would risk a lack of wholehearted cooperation from the project as a whole, erode the authority of the TC, and invite further discussion of the subject. I do think its a useful requirement to avoid $adjective GRs like this one (or at least make them harder). In practice I think that the developers as a whole are mature enough to take that into consideration in the way they vote. Bdale asked me in private email why I had changed my mind on this point since I drafted that part of the constitution. Here's what I said: I'm not sure whether I would agree that the 2:1 supermajority is always wrong. Russ's scenario seems a good [example of a problem with it] to me, so perhaps I'm older and wiser. To be honest when the constitution was being discussed I don't remember anyone considering this point. But in this particular case the situation seems especially difficult. It's certainly clear that the whole thing is very politically charged. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21212.22045.29176.529...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
Guillem Jover writes (Re: GR: Selecting the default init system for Debian): On Sun, 2014-01-19 at 12:04:17 +, 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. Actually, no, part of my reasons include several of the ones you list, as I tried to imply when writting “Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature,”. I should probably have been more explicit (seems to be a common fault of mine :/ ), but didn't want to go into specific details for those, I guess that was a mistake. :) Well of course the more we get into the details of the politics the more we risk unpleasantness. :-/. For example with strategic, I was thinking about things like: Thanks for your examples. Yes, I agree that these are important questions. However, I think your option (B) needs further reconsideration. I doubt the project will have the appetite for two GRs on this topic. Well, I'd rather not be spending time in the current GR either, I'd prefer to be doing something else instead, to be honest. But regarding option B, I'd also very strongly prefer if no other GR would appear, but I know that some people are eager to get a decision made and be done with it (even if it would get postponed now), and will not want to wait either, so that was more of a compromise than anything else. Perhaps there are options that make sense but that don't involve another GR. In practice I think few people would vote for a second GR so at the very least you might consider alternatives. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21212.22453.536649.647...@chiark.greenend.org.uk
Re: GR: Selecting the default init system for Debian
Hi Enrico! On Sun, 2014-01-19 at 14:56:27 +0100, Enrico Zini wrote: 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 don't agree these can be detangled, many reasons for such decision do have basis on non-technical questions (see my reply to Ian). So the other questions will keep being implicitly there even if it's supposedly just a “technical endorsement”. 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. To be frank, something I'd actually be very satisfied with, would be if the TC would have been requested or would decide to issue a set of non-binding informative documents, or a single or a set of non-binding recommendations for a default init system, to be used by people to decide, or to be added as additional explicit option(s) in the GR deferring to those recommendations. In fact, I think having a group of individuals (self-elected or not) on a workgroup doing focused research on difficult issues concerning project wide direction and presenting their findings and conclusions for consideration before the project in a non-binding form, would be excellent; and could help those who are undecided, don't have the time or energy to expend getting informed, or would like to defer completely their decision to that workgroup, for example. But as it stands I think I'm a bit conflicted here, on one hand the whole point of the GR is because I don't agree the TC should be _deciding_ on this, the project should, but on the other I acknowledge there's people that for whatever reason want to defer to the TC. So, because that's obviously the will of a part of the project, and because an amendment to the GR would be proposed most probably anyway, I guess I should just add an option deferring to the TC. Although ideally I think the scenario presented above would satisfy everyone, if the GR is going to be held anyway. 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. Honestly, I don't see how that would get us anywhere. We already have https://wiki.debian.org/UpstreamGuide. Adding something like this to a binding ruling affecting Debian, targeted at upstreams, seems a bit arrogant to me, because upstreams that have a strong opinion that might diverge from our ruling will unlikely change their mind. I think this is best left to the one-to-one relationships our maintainers already have with upstream, at their discretion. We always have the option of forking, or not packaging upstream software if we so strongly disagree. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120040409.ga13...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
Guillem Jover guil...@debian.org writes: But as it stands I think I'm a bit conflicted here, on one hand the whole point of the GR is because I don't agree the TC should be _deciding_ on this, the project should, but on the other I acknowledge there's people that for whatever reason want to defer to the TC. So, because that's obviously the will of a part of the project, and because an amendment to the GR would be proposed most probably anyway, I guess I should just add an option deferring to the TC. Although ideally I think the scenario presented above would satisfy everyone, if the GR is going to be held anyway. One way to think of this option is that it's the further discussion option on the GR that you're considering, except more explicit about what the implications are. Honestly, I don't see how that would get us anywhere. We already have https://wiki.debian.org/UpstreamGuide. Adding something like this to a binding ruling affecting Debian, targeted at upstreams, seems a bit arrogant to me, because upstreams that have a strong opinion that might diverge from our ruling will unlikely change their mind. Yes, exactly. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppnnff48@windlord.stanford.edu
GR: Selecting the default init system for Debian
[ 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)), because the TC seems to have been trying to do design work (failing §6.3(5)), 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)), I feel it's inappropriate for a small group of individuals to forcibly 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. I feel that such decisions must belong to the project at large. Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. If they had done so, Debian could follow its usual organic and decentralized process, allowing the best solution for the project as a whole to emerge naturally through the consensus formed from the experience of these deployments. Instead, we have seen giant flamewars seemingly based largely on speculation, which have only made the situation worse by increasing acrimony within the project, with further polarization and antagonization between the different factions. IMO, forcing this issue via a small committee will not improve this in any way. 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. I think it's pernicious for the project to instill a regime of threats and force, that will almost always alienate at least one side of a dispute. It clearly denotes a dysfunctional project. It has even crossed my mind many times now, to propose a GR for each issue concerning project direction (if not all) escalated to the TC, or even propose a constitutional change to remove the TC's powers of coercion; restricting its rulings to be strictly advisory and non-binding, though I'm not sure this option would get wide traction amongst developers, if at all. I've been sitting back and trying to see the extent to which other developers support the view that the TC should not be deciding on issues of project direction; unfortunately, canvassing support from mailing lists is difficult, and handling a GR is quite a large undertaking, requiring a lot of time and energy, that others might not want or be able to invest, but would gladly get behind. So, with much reluctance and disappointment, I've finally caved and am considering proposing the following GR draft. Unfortunately nothing has changed up to this point; the TC is not backing off. I think the draft text should cover most of the options people seem to have expressed support for up to now. Note that it's not entirely clear how a _pending_ resolution by the TC would interact with a GR on the same, so I'd like input from the secretary before seeking support from sponsors, although to be honest I don't expect any problems here. ,--- DRAFT GR TEXT --- A General Resolution to select the default init system for Debian. Option A * Reinforce sysvinit and sysv-rc as the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option B * Changing the default init system is ultimately desirable, but premature at this point in time. - supporters of other init systems should continue their efforts towards full adoption by Debian through guidance in the policy manual, natural formation of consensus, and wider support through Debian packages by persuading maintainers to accept patches to add support. - if a broad consensus cannot be reached before jessie+1, another GR could be held to determine the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option C * Switch to sysvinit + OpenRC wherever available. - architectures where OpenRC is not currently available will switch whenever OpenRC has been ported, retaining their current default in the meantime. - a reimplementation of OpenRC, providing the same interfaces to the wider system, would satisfy the criteria above. - the level of support for each init system would depend on the release status of the architecture: lack of
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
Re: GR: Selecting the default init system for Debian
Hi Guillem, On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. Setting aside the question of whether the TC should take this decision (which there's no point in discussing, as it's clearly your right to bring a GR if you disagree on this), can I ask how you arrived at the conclusion that not much energy has been expended on upstart in Debian? I've actually spent quite a lot of time and energy on getting upstart, and other base system packages, into a state that users should be able to switch from sysvinit to upstart without regressions. That means getting the ifupdown integration in place, making sure lvm and network filesystems work at boot, ensuring transparent handling of startpar dependencies on scripts that are shadowed by native upstart jobs, etc. It does *not* mean doing very much work on pushing native upstart jobs to maintainers of leaf packages; that should be secondary to getting a complete and correct base into Debian. But we certainly are at the point today where such jobs can be implemented more widely in packages. If you have a different standard for seeking wide deployment, I'm interested to know what it is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
