Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie
On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote: On 02/18/2014 09:34 PM, Jason Frothingham wrote: ... Adopting systemd does not, in any way shape, form, idea, concept, conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc. etc. the goal of a computationally stable, bug-free, and flexible operating system.� First of all, YES it does.. and a lot.. and the majority of competent Debian users know this, and that is why you are catching so much hell over putting it Since you must have spoken to the majority of competant Debian users to know this... Could you write up a report of exactly what they said please it would be very helpful. Or point to the report you read and quoted? If not, then stop with the lies and the FUD. into Debian. And this is why so many people are coming out of the woodwork to express their concerns.. they are concerned about the integrity (stable, You're the third. Perhaps you three the only competant Debian users? bug-free, flexible) of Debian as a viable server and general purpose operating system for critical applications.. and they don't want it screwed with! You seem to think that you wont be able to chose not to use Systemd - so you've not read very much of the debate or done much research. Here is a clue. Systemd will never make it onto the non-linux ports, so there will always be at least one other init available. You will always have a choice. And you could step up to maintain more choice in Debian if you so desired rather than telling other volunteers what to do. That is the Debian way. I have been coding since the early 80's, so please don't go there with me, it doesn't work. I don't care about systemd's capabilities.. that is a mute point. Perhaps you meant a moot point. A mute point would be very quiet indeed. Lots of other people do care and have said so in this debate. I happen to be one using a lot of the new features to great effect, on desktops. AND SERVERS. All I need to know is that it is an overly complicated, unnecessary piece of crapware that reduces the integrity of the distribution and that is all that matters. You have to specific or you'll be accused of FUD. Hand waving and shouting does not count. _Can_ you give more information on how it is overcomplicated? Or unnecessary? Or crap? If not... quit with the lies and the FUD. As to you initial question about what I would have the developers do.. I would say do just that.. develop Debian software that continues to make it a truly universal operating system and follows the original intent of the Debian way. Could you quote what the Debian way is? Are you a DD involved in defining that elusive thing? For _me_ one part of Debian has always to excell in making amazing technology and code available for everyone. Times have changed in twenty years. The linux kernel is not the same as it was in 1991. Computers are not used in the same static ways. Debian has to support a huge range of very dynamic systems now, and sysV just does not cut it. Sure it works _ok_ on static environments - but Debian supports far more than static servers. Debian has been around almost as long as the Internet itself.. Debian was started in 1993. The internet... try about 1973. Yes Debian is half the age of the internet. It is nearly as old as the Linux kernel, and not that much younger than GNU, but your point is invalidated by lack of truth. there are a lot of users out here that don't want to see anyone mess it up! ..Figure out a way around being stuck having to use udev since it has been co-opted by systemd.. that would be my first task for you! If you don't want udev, then try Debian Potato. It might make you happy and will forever have sysvinit. And please stop with the FUD and other trolling. Regards On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford t...@accesslab.com wrote: Putting the systemd issue on bugs.debian.org is a bit ridiculous I would say! As to why there are developers within Debian who are hellbent on turning Debian into buggy desktop software rather than keeping with the universal operating system directive.. I will never know! Debian is a major force in global server software and therefore must remain extremely stable, bug-free, and flexible.. all of which systemd/gnome crapware nullifies! -- Tony Thedford Access Technologies 850 Belt Line Rd Garland, TX 75040 Phone: 972.414.8356 Email: t...@accesslab.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: [mjr.org] Re: Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie
It is just as I thought.. incompetence has taken control. Good luck with that. On 02/19/2014 08:30 AM, Paul Hedderly wrote: On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote: On 02/18/2014 09:34 PM, Jason Frothingham wrote: ... Adopting systemd does not, in any way shape, form, idea, concept, conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc. etc. the goal of a computationally stable, bug-free, and flexible operating system.� First of all, YES it does.. and a lot.. and the majority of competent Debian users know this, and that is why you are catching so much hell over putting it Since you must have spoken to the majority of competant Debian users to know this... Could you write up a report of exactly what they said please it would be very helpful. Or point to the report you read and quoted? If not, then stop with the lies and the FUD. into Debian. And this is why so many people are coming out of the woodwork to express their concerns.. they are concerned about the integrity (stable, You're the third. Perhaps you three the only competant Debian users? bug-free, flexible) of Debian as a viable server and general purpose operating system for critical applications.. and they don't want it screwed with! You seem to think that you wont be able to chose not to use Systemd - so you've not read very much of the debate or done much research. Here is a clue. Systemd will never make it onto the non-linux ports, so there will always be at least one other init available. You will always have a choice. And you could step up to maintain more choice in Debian if you so desired rather than telling other volunteers what to do. That is the Debian way. I have been coding since the early 80's, so please don't go there with me, it doesn't work. I don't care about systemd's capabilities.. that is a mute point. Perhaps you meant a moot point. A mute point would be very quiet indeed. Lots of other people do care and have said so in this debate. I happen to be one using a lot of the new features to great effect, on desktops. AND SERVERS. All I need to know is that it is an overly complicated, unnecessary piece of crapware that reduces the integrity of the distribution and that is all that matters. You have to specific or you'll be accused of FUD. Hand waving and shouting does not count. _Can_ you give more information on how it is overcomplicated? Or unnecessary? Or crap? If not... quit with the lies and the FUD. As to you initial question about what I would have the developers do.. I would say do just that.. develop Debian software that continues to make it a truly universal operating system and follows the original intent of the Debian way. Could you quote what the Debian way is? Are you a DD involved in defining that elusive thing? For _me_ one part of Debian has always to excell in making amazing technology and code available for everyone. Times have changed in twenty years. The linux kernel is not the same as it was in 1991. Computers are not used in the same static ways. Debian has to support a huge range of very dynamic systems now, and sysV just does not cut it. Sure it works _ok_ on static environments - but Debian supports far more than static servers. Debian has been around almost as long as the Internet itself.. Debian was started in 1993. The internet... try about 1973. Yes Debian is half the age of the internet. It is nearly as old as the Linux kernel, and not that much younger than GNU, but your point is invalidated by lack of truth. there are a lot of users out here that don't want to see anyone mess it up! ..Figure out a way around being stuck having to use udev since it has been co-opted by systemd.. that would be my first task for you! If you don't want udev, then try Debian Potato. It might make you happy and will forever have sysvinit. And please stop with the FUD and other trolling. Regards On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford t...@accesslab.com wrote: Putting the systemd issue on bugs.debian.org is a bit ridiculous I would say! As to why there are developers within Debian who are hellbent on turning Debian into buggy desktop software rather than keeping with the universal operating system directive.. I will never know! Debian is a major force in global server software and therefore must remain extremely stable, bug-free, and flexible.. all of which systemd/gnome crapware nullifies! -- Tony Thedford Access Technologies 850 Belt Line Rd Garland, TX 75040 Phone: 972.414.8356 Email: t...@accesslab.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Putting the systemd issue on bugs.debian.org is a bit ridiculous I would say! As to why there are developers within Debian who are hellbent on turning Debian into buggy desktop software rather than keeping with the universal operating system directive.. I will never know! Debian is a major force in global server software and therefore must remain extremely stable, bug-free, and flexible.. all of which systemd/gnome crapware nullifies! -- Tony Thedford Access Technologies 850 Belt Line Rd Garland, TX 75040 Phone: 972.414.8356 Email: t...@accesslab.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
question for you: which would you have Debian developers do: A: complain about historical issues in systemd that have largely been patched or addressed B: complain about what systemd is like now C: submit patches to systemd that fix outstanding bugs D: submit patches to systemd that fix outstanding bugs and enable the non-initialization portions of systemd to work with other initialization systems like OpenRC If you selected A or B, I think I can identify your problem. You seem to have a mind set more typical of Moronix or Microsoft in which the existence of software packages *in the past* is all those software packages *will ever be in the future*. While that might be an accurate assumption to be made of proprietary software that is largely published and then only patched when something breaks, such models are generally not true to Open Source Software packages like KDE, the Linux Kernel, or Libre Office. Such software packages typically learn from coding mistakes in the past and new versions actively address various issues. E.G. a very popular point right now is how the lessons and resources from the Nepomuk development are being leveraged in the development of Nepomuk 2.0, aka Baloo. :: Another popular point in recent weeks can be found in the Open-Source X.org Radeon drivers starting to trade blows in OpenGL 3.x class rendering with the proprietary Catalyst driver set. :: Need I continue? Now, I won't argue that the Gnome-Shell software is crapware; and you won't find me arguing against similar points on GTK in general. The Gnome-Shell and GTK developers are formed of infamous cliques that have done more to discourage modern developers than encourage them. Need I point out Valve's observations on the differences between QT and GTK development and the interaction with upstream developers... or in the case of GTK... the lack of interaction with upstream and existing developers. I will argue that writing off systemd so quickly is a huge mistake. Do keep in mind that with less than half the development time (2010~2014) compared to Canonical's Upstart (2006~2014), the systemd initialization system alone managed to reach at least on-paper parity; if not in-practice parity; with the older software package. A large part of that rapid pace of comparative development was the loss of FOSS oriented developers who chafed at Canonical's CLA licensing modification. No, I'm not letting that one go, it is that big a deal: especially for Debian's stances on Software licensing. Are such statements to be an understanding or equivalency as a statement that systemd is a perfect software solution? *NO*. Nobody here on Debian even got close to suggesting such a thing. The closest anybody here on these mailing lists got were statements that as of right now, *systemd is better than SysVInit on Linux.* Adopting systemd does not, in any way shape, form, idea, concept, conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc. etc. the goal of a computationally stable, bug-free, and flexible operating system. So do this, and other mailing lists a favor, knock off the Fear, Uncertainty, and Doubt. if you have the coding chops to actually comment on systemd's capabilities and features; or lack-thereof; at a code level rather than just at a Moronix Level, you'd probably be better off diving in and fixing bugs yourself. On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford t...@accesslab.com wrote: Putting the systemd issue on bugs.debian.org is a bit ridiculous I would say! As to why there are developers within Debian who are hellbent on turning Debian into buggy desktop software rather than keeping with the universal operating system directive.. I will never know! Debian is a major force in global server software and therefore must remain extremely stable, bug-free, and flexible.. all of which systemd/gnome crapware nullifies! -- Tony Thedford Access Technologies 850 Belt Line Rd Garland, TX 75040 Phone: 972.414.8356 Email: t...@accesslab.com -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530411b8.7060...@accesslab.com -- Jason Frothingham. http://www.linux-guides.com http://http://forum.mepiscommunity.org/ http://www.mepis.org http://www.gamenikkiinexile.com http://gplus.to/JeSaist
Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie
On 02/18/2014 09:34 PM, Jason Frothingham wrote: ... Adopting systemd does not, in any way shape, form, idea, concept, conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc. etc. the goal of a computationally stable, bug-free, and flexible operating system.� First of all, YES it does.. and a lot.. and the majority of competent Debian users know this, and that is why you are catching so much hell over putting it into Debian. And this is why so many people are coming out of the woodwork to express their concerns.. they are concerned about the integrity (stable, bug-free, flexible) of Debian as a viable server and general purpose operating system for critical applications.. and they don't want it screwed with! So do this, and other mailing lists a favor, knock off the Fear, Uncertainty, and Doubt. �if you have the coding chops to actually comment on systemd's capabilities and features; or lack-thereof; at a code level rather than just at a Moronix Level, you'd probably be better off diving in and fixing bugs yourself.� I have been coding since the early 80's, so please don't go there with me, it doesn't work. I don't care about systemd's capabilities.. that is a mute point. All I need to know is that it is an overly complicated, unnecessary piece of crapware that reduces the integrity of the distribution and that is all that matters. As to you initial question about what I would have the developers do.. I would say do just that.. develop Debian software that continues to make it a truly universal operating system and follows the original intent of the Debian way. Debian has been around almost as long as the Internet itself.. there are a lot of users out here that don't want to see anyone mess it up! ..Figure out a way around being stuck having to use udev since it has been co-opted by systemd.. that would be my first task for you! On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford t...@accesslab.com mailto:t...@accesslab.com wrote: Putting the systemd issue on bugs.debian.org http://bugs.debian.org is a bit ridiculous I would say! As to why there are developers within Debian who are hellbent on turning Debian into buggy desktop software rather than keeping with the universal operating system directive.. I will never know! Debian is a major force in global server software and therefore must remain extremely stable, bug-free, and flexible.. all of which systemd/gnome crapware nullifies! -- Tony Thedford Access Technologies 850 Belt Line Rd Garland, TX 75040 Phone: 972.414.8356 Email: t...@accesslab.com
Bug#727708: call for votes on default Linux init system for jessie
* Bdale Garbee (bd...@gag.com) [140208 20:50]: I expect that Debian can and should continue to support multiple init systems for the foreseeable future. I also believe that Debian can and should take an active role working with upstream projects on software that is important to us, such as init system projects. [...] - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I'm unhappy with this resolution; in fact, after the discussions I don't think it would be good to decide on an init system without explicitly stating that users should be able to continue to make different decisions on their own systems (and in hindsight it was an error that I voted FD on the previous call for votes to allow textual optimizations). This is especially true for systemd (I consider the probability of people to depend soley on upstart to be lower) - after some long thinking about this I came to the conclusion that I cannot vote systemd above further discussion in the current scenario. (Also I hope but don't expect that the discussions we had on our list are enough for maintainers to not try to force a specific init system on our users.) Thus voting U, F, D, O, V. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
Bdale Garbee bd...@gag.com writes:
- - - start ballot - - -
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be
Dsystemd
Uupstart
Oopenrc
Vsysvinit (no change)
Frequires further discussion
Should the project pass a General Resolution before the release of
jessie asserting a position statement about issues of the day on
init systems, that position replaces the outcome of this vote and is
adopted by the Technical Committee as its own decision.
- - - end ballot - - -
I vote D U O V F.
On Sat, Feb 08, 2014 at 12:16:51PM -0800, Russ Allbery wrote:
I vote:
D U O V F
On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
I vote F U D O V
On Sat, Feb 08, 2014 at 02:51:13PM -0800, Don Armstrong wrote:
I vote D U O V F.
On Sat, Feb 08, 2014 at 02:57:52PM -0800, Keith Packard wrote:
I vote:
1. D
2. U
3. O
4. V
5. F
On Sun, Feb 09, 2014 at 01:04:31PM +, Colin Watson wrote:
I vote UDOFV.
On Sun, Feb 09, 2014 at 07:15:58PM +, Ian Jackson wrote:
I vote F, V, O, U, D.
On Tue, Feb 11, 2014 at 09:07:11AM +0100, Andreas Barth wrote:
Thus voting U, F, D, O, V.
So that's all the votes in, by my count. Summary is:
4x D U O V F (bdale, russ, keith, don)
F U D O V (steve)
U D O F V (colin)
F V O U D (ian)
U F D O V (andi)
Pairwise defeats are:
D = U (4:4)
U and D O and V
(7:1) (ian against)
O V (7:1) (ian against)
U F (6:2) (steve, ian against)
D F (5:3) (steve, ian, andi against)
O F (5:3) (steve, ian, andi against)
V = F (4:4)
A.6.2: Quorum is 2 (6.3.1), all options meet quorum.
A.6.3: Option V does not strictly defeat default option F, so is eliminated
A.6.5: Transitive defeats are:
D : O, F (directly)
U : O, F (directly)
O : F (directly)
F :
A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
the casting vote chooses which of these options wins.
Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.
Per 6.3.1, the voting period expires either Feb 15th, or when the outcome
is no longer in doubt. Not clear to me if that's now, or only after Bdale
specifies a casting vote. Per 7.3, if there's any dispute about that, the
secretary adjudicates that dispute.
Cheers,
aj
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Anthony Towns a...@erisian.com.au writes:
A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
the casting vote chooses which of these options wins.
Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.
Thank you, Anthony, for your analysis of the votes.
Per 6.3.2, I use my casting vote to choose D as the winner.
Therefore, the resolution reads:
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be systemd.
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.
Bdale
pgpXfABKHHLNO.pgp
Description: PGP signature
Bug#727708: [Fwd: Re: Bug#727708: call for votes on default Linux init system for jessie]
---BeginMessage---
Anthony Towns a...@erisian.com.au writes:
A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
the casting vote chooses which of these options wins.
Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.
Thank you, Anthony, for your analysis of the votes.
Per 6.3.2, I use my casting vote to choose D as the winner.
Therefore, the resolution reads:
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be systemd.
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.
Bdale
How can you make this statement when the voting period is not over?
What if some CTTE members decide to change their vote? Andreas Barth
changed his vote today!
---End Message---
Bug#727708: [Fwd: Re: Bug#727708: call for votes on default Linux init system for jessie]
On 11/02/14 16:09, Svante Signell wrote: How can you make this statement when the voting period is not over? What if some CTTE members decide to change their vote? Debian Constitution 6.3.1: the voting period lasts for up to one week, or until the outcome is no longer in doubt. Given that all eight committee members have voted and the outcome is no longer in doubt, the voting period is over and the chairman of the committee can use his casting vote. Andreas Barth changed his vote today! No, he hasn't changed his vote. He has voted today but he hasn't changed his vote as he hadn't voted before on this resolution. That is why the outcome was still in doubt, as Andreas could have ranked D above U, making the outcome different (just D in the Schwartz set and no need for the casting vote). Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 07:35:13AM -0700, Bdale Garbee wrote:
Anthony Towns a...@erisian.com.au writes:
A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
the casting vote chooses which of these options wins.
Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.
Thank you, Anthony, for your analysis of the votes.
Per 6.3.2, I use my casting vote to choose D as the winner.
FWIW I have always assumed that the casting vote is implicit in the chair's
ballot. To require the chair to explicitly exercise their casting vote, as
opposed to the chair's preferences as expressed on the ballot being applied
automatically, opens up another set of vote gaming strategies that we really
shouldn't get into.
(Obviously there's no gaming here, as Bdale's casting vote is consistent
with his ballot; but let's not set a bad precedent...)
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek vor...@debian.org writes: FWIW I have always assumed that the casting vote is implicit in the chair's ballot. To require the chair to explicitly exercise their casting vote, as opposed to the chair's preferences as expressed on the ballot being applied automatically, opens up another set of vote gaming strategies that we really shouldn't get into. I would have assumed that, too, but since others did not share the assumption, it seemed prudent to be explicit about it. I suppose it's always possible that the chair might change their mind after seeing how votes are cast and the comments associated with those votes. Should the project choose to try and amend the constitution at some point to address corner cases in the voting process or TC rules of engagement exposed through this process, this might be a detail worth addressing explicitly. On the other hand, we have never needed the TC casting vote before, and I sincerely hope we never do again. Bdale pgpkuNdIVjEiV.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Bdale == Bdale Garbee bd...@gag.com writes: Bdale Steve Langasek vor...@debian.org writes: FWIW I have always assumed that the casting vote is implicit in the chair's ballot. To require the chair to explicitly exercise their casting vote, as opposed to the chair's preferences as expressed on the ballot being applied automatically, opens up another set of vote gaming strategies that we really shouldn't get into. Bdale I would have assumed that, too, but since others did not Bdale share the assumption, it seemed prudent to be explicit about Bdale it. This assumption does not make sense to me in the following cases: * Chair ranks multiple options equilly * All of the options that the chair is choosing between were ranked by the chair below FD * At least one of the options was not ranked by the chair. * I don't know if casting votes can come up in DPL elections or if there are any other circumstances with secret ballots. I think you're safer just casting an explicit casting vote. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote: Bdale == Bdale Garbee bd...@gag.com writes: Bdale Steve Langasek vor...@debian.org writes: FWIW I have always assumed that the casting vote is implicit in the chair's ballot. To require the chair to explicitly exercise their casting vote, as opposed to the chair's preferences as expressed on the ballot being applied automatically, opens up another set of vote gaming strategies that we really shouldn't get into. Bdale I would have assumed that, too, but since others did not Bdale share the assumption, it seemed prudent to be explicit about Bdale it. This assumption does not make sense to me in the following cases: * Chair ranks multiple options equilly If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? Or, put differently: if the chair comes to a decision about which of the equally-ranked options should win, why should that decision not be reflected in his main vote (with the effect that the casting vote will not be used at all)? * All of the options that the chair is choosing between were ranked by the chair below FD Being below FD does not imply that no preference is being expressed between the options. Rankings between such options are taken into account at every other stage of the vote, there's no reason it should be different for the casting vote. * At least one of the options was not ranked by the chair. Unranked options are treated as ranked last, so whichever option is *not* unranked gets the vote. * I don't know if casting votes can come up in DPL elections or if there are any other circumstances with secret ballots. If they are, why should the casting vote be less secret than the normal ballot? I think you're safer just casting an explicit casting vote. The only case in which it makes a difference to have an explicit casting vote is when the preferences expressed in the casting vote do not match the preferences expressed in the standard vote. If that ever happened, it would be an act of strategic voting. When all other aspects of our voting system are designed to minimize the rewards of strategic voting, this seems an unnecessary bug. It's a low-impact bug, because it requires both three nearly-balanced ballot options, and a TC chair willing to engage in strategic voting for all the world to see; but it's still a bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote: On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote: Bdale == Bdale Garbee bd...@gag.com writes: Bdale Steve Langasek vor...@debian.org writes: FWIW I have always assumed that the casting vote is implicit in the chair's ballot. To require the chair to explicitly exercise their casting vote, as opposed to the chair's preferences as expressed on the ballot being applied automatically, opens up another set of vote gaming strategies that we really shouldn't get into. Bdale I would have assumed that, too, but since others did not Bdale share the assumption, it seemed prudent to be explicit about Bdale it. This assumption does not make sense to me in the following cases: * Chair ranks multiple options equilly If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? I think the vote should always result in something, and as such the person having the casting vote needs to pick one of the options that are left in the Schwartz set. If there was no preference between them, a choise will still need to be made. I've actually been wondering about this issue myself the past few days, and this seems to me the only good reason why the casting vote should be a different vote than the earlier vote. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek vor...@debian.org writes: If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? Oh, the obvious answer -- if the chair's preference didn't end up in the tie, he'd have to explicitly vote from the remaining options. -- keith.pack...@intel.com pgpn74_7yOsAq.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote: I think the vote should always result in something, and as such the person having the casting vote needs to pick one of the options that are left in the Schwartz set. If there was no preference between them, a choise will still need to be made. I have, when serving as a chair of an association meeting, voted blank in many occasions, and in the one case where it resulted in a tie, I used my casting vote to resolve it. In those cases, it was not important for me to choose between the options during the regular vote, hence the blank vote. However, when the vote resulted in a tie, I had an obligation, imposed by law, custom and the association's constitution, to choose; and I did. However, in any vote where I as a chair have already voted non-blank, I feel it would be wrong for me to choose another option for my casting vote. Of course, the rules of order for a Finnish association are rather different from those used by Debian's TC, so there's no direct relevance to this case. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 11:54:50AM -0800, Keith Packard wrote: Steve Langasek vor...@debian.org writes: If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? Oh, the obvious answer -- if the chair's preference didn't end up in the tie, he'd have to explicitly vote from the remaining options. Obvious, but wrong. We use Condorcet to enable fully expressing our preferences among all the ballot options, not just our first-choice preference. The chair using a casting vote between two tied options (or three, which is the problematic case) is expressing a preference for one over the other; if such a preference exists, the non-strategic vote is to express this same preference in the original ballot. The *only* use of a casting vote that is different from the original ballot is a strategic one, and we should never allow this. In the case described, the chair should just express the preference between the remaining options (perhaps by amending their vote, which is allowed so long as the outcome is in doubt), in which case the casting vote clause doesn't come into play at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
]] Steve Langasek The *only* use of a casting vote that is different from the original ballot is a strategic one, and we should never allow this. In the case described, the chair should just express the preference between the remaining options (perhaps by amending their vote, which is allowed so long as the outcome is in doubt), in which case the casting vote clause doesn't come into play at all. The vote might have ran out of time, in which case I believe it's too late to change any votes, but not to use the casting vote. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Hi, Steve Langasek: Obvious, but wrong. We use Condorcet to enable fully expressing our preferences among all the ballot options, not just our first-choice preference. The chair using a casting vote between two tied options (or three, which is the problematic case) is expressing a preference for one over the other; if such a preference exists, the non-strategic vote is to express this same preference in the original ballot. The chair might desire to use their casting vote to select the more popular | less controversial | more- (or less-)vocally-supported option, as opposed to their personal opinion | preference. The *only* use of a casting vote that is different from the original ballot is a strategic one, and we should never allow this. I disagree. -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Matthias Urlichs sm...@smurf.noris.de writes: Steve Langasek: Obvious, but wrong. We use Condorcet to enable fully expressing our preferences among all the ballot options, not just our first-choice preference. The chair using a casting vote between two tied options (or three, which is the problematic case) is expressing a preference for one over the other; if such a preference exists, the non-strategic vote is to express this same preference in the original ballot. The chair might desire to use their casting vote to select the more popular | less controversial | more- (or less-)vocally-supported option, as opposed to their personal opinion | preference. Can I suggest that this discussion may be better placed in debian-project? The procedural issue is really a concern for the project as a whole, and any changes would be constitutional changes and would have to go through the project as a whole. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote: On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote: On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote: Bdale == Bdale Garbee bd...@gag.com writes: Bdale Steve Langasek vor...@debian.org writes: FWIW I have always assumed that the casting vote is implicit in the chair's ballot. To require the chair to explicitly exercise their casting vote, as opposed to the chair's preferences as expressed on the ballot being applied automatically, opens up another set of vote gaming strategies that we really shouldn't get into. Bdale I would have assumed that, too, but since others did not Bdale share the assumption, it seemed prudent to be explicit about Bdale it. This assumption does not make sense to me in the following cases: * Chair ranks multiple options equilly If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? I think the vote should always result in something, and as such the person having the casting vote needs to pick one of the options that are left in the Schwartz set. If there was no preference between them, a choise will still need to be made. I've actually been wondering about this issue myself the past few days, and this seems to me the only good reason why the casting vote should be a different vote than the earlier vote. Somewhere buried in this huge thread I had a discussion with Anthony regarding it, and in my opinion there is another possible good reason: Assume in Ian's previous combined ballot where voting was aborted the two remaining members would have voted, and both had voted DT DL FD. The result would have been: DT FD (5:3) DL FD (8:0) DT = DL (4:4) One can argue that the the chairman should simply pick whatever he personally prefers. My point here is that the chairman should IMHO at least consider the fact that there is one option that is acceptable for all members, while the other option is vehemently opposed by 3 TC members. And choosing a generally acceptable option over his personal preference would be a good reason for voting different in the casting vote.[1] Kurt cu Adrian [1] The chairman has no obligation to change his vote in such a case, but if he would there would be a good reason and not just random erratic behaviour. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
I vote: V U O :) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 11:51 PM, Don Armstrong d...@debian.org wrote: I vote D U O V F. I would appreciate it if you could reply to self with signed mail re-stating this. Thanks, Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote: I have carefully considered Ian's current proposal for a process and schedule to reach a next ballot on the init system issue, and do not believe it is the best way for us to proceed. The fundamental problem is that I remain as convinced now as I was when I posted my last CFV that conflating multiple questions in a single ballot is a bad idea. Our voting system works exceptionally well when we're trying to choose between multiple alternatives for a single question. But as others have observed, trying to mix questions into a matrix of alternatives in a single ballot really complicates the process. I believe it both tempts us all to take a more tactical approach to voting than appropriate, and increases the risk of stumbling over corner cases in the process which could lead to surprising results. I have a lot of sympathy with Ian's position here, hence my previous FD votes; I think we do need to finish hashing this out, and it was valuable to run the combined votes (even abortively) since the combination certainly could have made a significant and important difference. However, looking through the votes cast so far, I do not see how separating them is actually going to make a discernible difference to the outcome of either part, and so I don't feel that I can personally justify holding things up any more for this. I also hope that resolving this part will vent a little pressure so that we can deal with the rest more effectively. As per Constitution 6.3.1, I call for an immediate vote on the following ballot, with a voting period of one week or until the outcome is no longer in doubt: - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. I vote UDOFV. -- Colin Watson [cjwat...@debian.org] signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Hi, Michael Gilbert: I'd be happy to see a change post-jessie, but I feel like it is a self-imposed rush to push anything through for jessie. Given that certain other distributions switched to systemd umpteen months ago, I see that less as rushing and more as we're late to the game and do NOT want to burden everybody with buggy init scripts, missing features, and an unmaintained pseudo-solution (ConsoleKit) for another two+ years. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sun, Feb 9, 2014 at 8:04 AM, Colin Watson wrote: I vote UDOFV. So, this vote effectively gives systemd the win (assuming Bdale opts for the casting vote). This trumps the fact that Steve was in the midst of drafting a potentially agreeable ballot all around, and had stated his disappointment about this out of the blue CFV since he just needed some more time to get that done. Wouldn't it be far more preferable to take a little more time to refine the text so that it can be backed by a somewhat unified TC? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote: I vote UDOFV. So, this vote effectively gives systemd the win (assuming Bdale opts for the casting vote). This trumps the fact that Steve was in the midst of drafting a potentially agreeable ballot all around, and had stated his disappointment about this out of the blue CFV since he just needed some more time to get that done. Many have voiced the concern I'm going to address, but as I see your words, I cannot help but see the need to reiterate. There is a point of view, that Steve's role as a debian's upstart maintainer is in a direct conflict with the spirit of the process here. From such a viewpoint, one would rather see Steve abstain from _any_ participation on bug #727708. In fact, one can't help but be amazed at the level of tolerance to this issue from other members of the CTTE. -- regards, Samium Gromoff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee writes (call for votes on default Linux init system for jessie): I have carefully considered Ian's current proposal for a process and schedule to reach a next ballot on the init system issue, and do not believe it is the best way for us to proceed. This unannounced CFV is an abuse of process. I am EXTREMELY ANGRY and I will sponsor any GR that seeks to overturn it. I vote F, V, O, U, D. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Keith Packard writes (Re: call for votes on default Linux init system for jessie): Let's finish that vote then and move on. Once again Bdale has proposed a vote on his own motion. However, my own proposal was on the table and has not been withdrawn. Bdale chose to put forward his ballot entirely on his own without giving me the chance to put forward amendments, and without putting his ballot forward as amendments to mine. Bdale has punished me for being a good citizen. I could have called for a vote on my own proposal without warning. Or indeed allowed my own last vote to carry on. This grievous abuse of process, when I have myself made it very clear what I expected, means that I have totally lost confidence in Bdale's position as TC chair. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On 10/02/2014 6:21 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Keith Packard writes (Re: call for votes on default Linux init system for jessie): Let's finish that vote then and move on. Once again Bdale has proposed a vote on his own motion. However, my own proposal was on the table and has not been withdrawn. Bdale chose to put forward his ballot entirely on his own without giving me the chance to put forward amendments, and without putting his ballot forward as amendments to mine. Bdale has punished me for being a good citizen. I could have called for a vote on my own proposal without warning. Or indeed allowed my own last vote to carry on. Just a heads up; you clearly stated in your original timeline email: If anyone jumps the gun on this schedule by calling for votes early and without gettign consensus the list, I think TC members who agree with my proposed schedule should rank FD first. If you think this schedule is wrong you will need to convince your fellow TC members to (a) vote FD on the 3rd CFV, to postpone again; or (b) refrain from voting FD on an earlier CFV. You have stated that people can hold other and earlier votes; and given that people are not voting FD first, that clearly indicates that they think Bdale's proposal is acceptable in it's current form and does not require amendments. You are free to vote FD if you feel otherwise. Regards, James.
Bug#727708: call for votes on default Linux init system for jessie
Serge Kosyrev skosy...@ptsecurity.ru writes: On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote: I vote UDOFV. So, this vote effectively gives systemd the win (assuming Bdale opts for the casting vote). This trumps the fact that Steve was in the midst of drafting a potentially agreeable ballot all around, and had stated his disappointment about this out of the blue CFV since he just needed some more time to get that done. Many have voiced the concern I'm going to address, but as I see your words, I cannot help but see the need to reiterate. There is a point of view, that Steve's role as a debian's upstart maintainer is in a direct conflict with the spirit of the process here. From such a viewpoint, one would rather see Steve abstain from _any_ participation on bug #727708. In fact, one can't help but be amazed at the level of tolerance to this issue from other members of the CTTE. Ondřej Surý ond...@sury.org writes: This has been repeated many times I have said so, indeed -- as well as stated a reason for reiteration. and refused False. Three messages on this list brought this conflict of interest into light: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5912 by Friedrich Gunther http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6206 by Dmitry Smirnov There was no answer. and I would really prefer that you would stop reiterating this again and again. It's really annoyning and it feels like you are not listening anf just blindly repeating your position. Please stop, you are not helping neither Debian nor the process. Such is your unexplained (and ill-substantiated) preference. -- regards, Samium Gromoff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Mon, Feb 10, 2014 at 12:41:38AM +0400, Serge Kosyrev wrote: Serge Kosyrev skosy...@ptsecurity.ru writes: On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote: I vote UDOFV. So, this vote effectively gives systemd the win (assuming Bdale opts for the casting vote). This trumps the fact that Steve was in the midst of drafting a potentially agreeable ballot all around, and had stated his disappointment about this out of the blue CFV since he just needed some more time to get that done. Many have voiced the concern I'm going to address, but as I see your words, I cannot help but see the need to reiterate. There is a point of view, that Steve's role as a debian's upstart maintainer is in a direct conflict with the spirit of the process here. From such a viewpoint, one would rather see Steve abstain from _any_ participation on bug #727708. In fact, one can't help but be amazed at the level of tolerance to this issue from other members of the CTTE. Ondřej Surý ond...@sury.org writes: This has been repeated many times I have said so, indeed -- as well as stated a reason for reiteration. Whether my conflict of interest in this decision constitutes a problem is a question for the Debian project to decide, not you. I have been convinced, as a result of conversations with my fellow TC members early in this process, that there was no need for me to recuse myself from the discussion. If the Debian Developers feel that my conflict of interest has resulted in a wrong decision being taken, they have the authority to override the TC with a GR. But until then, kindly stop distracting the committee from its rightful business. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On 10 February 2014 06:41, Serge Kosyrev skosy...@ptsecurity.ru wrote: False. Three messages on this list brought this conflict of interest into light: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns [...] There was no answer. So, fwiw, I thought the above was kind of mean on my behalf. Not /wrong/ per se, just mean. I haven't been able to think of a *good* answer for this concern, even in an arbitrary ideal world where the constraints are different. For instance, Steve could recuse himself from the discussion entirely -- that's what you'd expect in many cases where there are commercial conflicts of interest, eg. But that would be ridiculous here, because both his technical knowledge as upstart maintainer is nigh-on essential to the discussion, and his input as to how things have worked in Canonical is pretty useful too. He could recuse himself from voting, or perhaps the committee chair or committee as a whole could ask him to do so -- but at least at this point, that would be effectively equivalent to Steve directly voting systemd above upstart, and that would be a fairly unreasonable forced reversal of preferences for Steve to make, or it would involve a conflict of interest on behalf of the chair (who's indicated a preference for systemd), or the rest of the committee (which has indicated a 4:3 preference for systemd). Maybe one of these things would have been good to do earlier, before positions had coalesced, but I don't think they're reasonable things to do or expect now. (They might have been when I sent the mail, but if so, they only remained plausible for a pretty short window in my opinion; further, Steve mentions that the committee discussed this earlier and came to the conclusion that no action was needed) If the committee had the flexibility to do so, maybe a reasonable thing would have been to replace Steve for this vote with a less interested party early in the discussions; eg by letting Phil Kern step in to provide the 8th vote for this issue, so that Steve could simply act as an advocate and technical advisor to the committee on this issue. Alternatively, perhaps a reasonable thing might have been to give the primary systemd, sysvinit and upstart maintainers the ability to vote on this issue too. Neither were options open to the committee though. As it stands, though, Steve has to: consider the implications for Debian, consider the implications for upstart (as maintainer), consider the implications for Canonical and Ubuntu (as a Canonical employee and Ubuntu dev), mostly dismiss the implications for Canonical/Ubuntu (in order to prioritise the implications for Debian as a ctte member making a ctte decision), and deal with accusations of having a conflict of interest, despite not being able to do anything concrete to address them. Oh, and I gather Steve's trying to run a debconf in six months time or so too, which I understand could add some degree of stress on its own... So yeah, I stand by my description of that as fairly challenging, and I'm really glad it's not me in that position. Cheers, aj -- Anthony Towns a...@erisian.com.au -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
I have carefully considered Ian's current proposal for a process and schedule to reach a next ballot on the init system issue, and do not believe it is the best way for us to proceed. The fundamental problem is that I remain as convinced now as I was when I posted my last CFV that conflating multiple questions in a single ballot is a bad idea. Our voting system works exceptionally well when we're trying to choose between multiple alternatives for a single question. But as others have observed, trying to mix questions into a matrix of alternatives in a single ballot really complicates the process. I believe it both tempts us all to take a more tactical approach to voting than appropriate, and increases the risk of stumbling over corner cases in the process which could lead to surprising results. My other concern is that while it is clearly within our constitutional right, to the best of my recollection the committee has never before issued a binding ruling on an issue not explicitly put before it. Thus, a vote on the T vs L question in whatever form might evolve through further discussion seems precedent-setting to me... and thus deserves to be voted on discretely, so the outcome is clear and unambiguous input to the project. I expect that Debian can and should continue to support multiple init systems for the foreseeable future. I also believe that Debian can and should take an active role working with upstream projects on software that is important to us, such as init system projects. So... I want to try and simplify this again using essentially the same ballot I put forth before, but with all the concerns raised by other committee members addressed... except for Ian's demand that we conflate the T vs L question in the same vote. I understand this means Ian will most likely vote further discussion as his first choice, but I sincerely hope the rest of you will not do that and instead vote this ballot to a useful conclusion. I explicitly sought and have received our project Secretary's review of the text of this ballot. Both the assertion of jurisdiction and text allowing a GR to override our conclusion incorporate his inputs. As per Constitution 6.3.1, I call for an immediate vote on the following ballot, with a voting period of one week or until the outcome is no longer in doubt: - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - pgpZv6EAbT0kW.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee bd...@gag.com writes: - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I vote D U O V F. Bdale pgp_w2YL6fp7g.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee bd...@gag.com writes: The fundamental problem is that I remain as convinced now as I was when I posted my last CFV that conflating multiple questions in a single ballot is a bad idea. Our voting system works exceptionally well when we're trying to choose between multiple alternatives for a single question. But as others have observed, trying to mix questions into a matrix of alternatives in a single ballot really complicates the process. I believe it both tempts us all to take a more tactical approach to voting than appropriate, and increases the risk of stumbling over corner cases in the process which could lead to surprising results. Thank you. I'm strongly in agreement with this. The discussion over coupling is very important. I will be continuing that today, simultaneous with this. I think that Steve, Colin, and I are actually very close to wording that all three of us agree on, and which I suspect both Bdale and Keith will also agree with. I have some wording to propose today. I don't think that changes the merits of what Bdale says above. Yes, there is interplay between the various things that we want to decide, but iteratively narrowing the state space makes the ballots much more comprehensible and avoids wandering into corner cases of our voting method. I really disliked how tactical the analysis got with the combined ballot; to me, it feels against the spirit of how we're expected to try to resolve problems within Debian. The ability to hold multiple iterative votes on different angles of the question is a huge advantage of the TC process over the GR process. The latter has a variety of constraints that makes holding multiple rounds of votes incredibly painful. Given that our decision is likely to be reviewed by GR no matter what happens, I think we can take advantage of our faster voting turnaround to try to at least sketch out a few reasonable courses of action that have support from sections of the TC, which can in turn provide useful input into what GR questions people may want to propose. - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I vote: D U O V F -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ pgpbEOWHlbWzW.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote: So... I want to try and simplify this again using essentially the same ballot I put forth before, but with all the concerns raised by other committee members addressed... except for Ian's demand that we conflate the T vs L question in the same vote. I understand this means Ian will most likely vote further discussion as his first choice, but I sincerely hope the rest of you will not do that and instead vote this ballot to a useful conclusion. I agree with Ian on this. At this point, it should be clear to everyone that, given the stated preferences of each member of the TC, the default init system for jessie will be systemd. But I do not think this is the most important aspect of the problem that needs to be decided. The question of how, or if, multiple init systems will coexist in the Debian archive for jessie is what needs to be decided in order to unblock maintainers and give them clarity for their own packages. The only thing that an up/down vote on init systems does is placate the crowds of onlookers who are not part of Debian's decision-making processes, at the expense of settling the more nuanced questions that need to be answered for the project. This should not be our priority. Our purpose here is to make sound technical decisions on behalf of the project, not to preserve the TC's (or Debian's) reputation among third parties who have no legitimate say in the outcome. I will note for the record here that a number of DDs have at this point given the TC an ultimatum in private, stating that they will start a GR if the TC does not call for votes within a specified time limit. I suspect that this ultimatum didn't have much effect on Bdale's decision to call for a vote (since he was already predisposed to having the up/down vote in question). Likewise, such an ultimatum doesn't change my view about what ballot should be voted and when. And every DD has a constitutional right to start a GR on this question, at any point. But it's highly inappropriate to attempt to pressure the TC into making a quick decision using the *threat* of a GR. TC decisions take time precisely because they deal with nuanced issues that don't get handled any other way. Rushing to a vote only delays efforts to reach a consensus in the project, and is counter to the long-term health of Debian. - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I vote F U D O V I will also point out that splitting this issue into separate ballots in no way prevents tactical voting, particularly given the small pool of voters and the resulting likelihood of voting blocks. If I were less committed to the integrity of this process, I might have used burying to vote a ballot like: U F O V D But seeing as I do value the integrity of the process, I will instead confine myself to observing that I think it's very rude to call a vote while other members of the committee have made it clear they are still engaged in discussion to identify ballot options that the whole committee can support. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek vor...@debian.org writes: I agree with Ian on this. At this point, it should be clear to everyone that, given the stated preferences of each member of the TC, the default init system for jessie will be systemd. But I do not think this is the most important aspect of the problem that needs to be decided. The question of how, or if, multiple init systems will coexist in the Debian archive for jessie is what needs to be decided in order to unblock maintainers and give them clarity for their own packages. Given that you feel like it's clear what the default init system will be, and given that the previous rounds of partial voting show that the choice of dependency models will have no effect on that outcome, I don't see any point in delaying this part of the decision. You feel like this is all but decided; fine, let's decide it, so that we have a decision on record, and then continue the discussion. Or, put another way, why *don't* you want to vote on this right now? That it's not the most important question is not a reason to delay voting on it; if anything, it's a reason to vote on it first, so that we can dispose of the questions with clear answers while we're working on language for the more complex options. We held the ballot to entangle it with other questions on the assumption that this entangling may change the result for the primary question. It turns out that this is not the case, so there was no need for that entangling. I would really like to establish things that you think are already apparent so that we have some forward progress and so that we don't have to hold open sockets for things that we think are *probably* decided but that we've not yet actually decided. If you feel like deciding this will mean losing some momentum on a question that you consider more important, I personally commit to continuing the discussions on that process and working on a ballot and arriving at a decision as quickly as possible. I don't think any of us intend to abandon this discussion once the init system default on Linux is decided. I will note for the record here that a number of DDs have at this point given the TC an ultimatum in private, stating that they will start a GR if the TC does not call for votes within a specified time limit. I suspect that this ultimatum didn't have much effect on Bdale's decision to call for a vote (since he was already predisposed to having the up/down vote in question). Likewise, such an ultimatum doesn't change my view about what ballot should be voted and when. And every DD has a constitutional right to start a GR on this question, at any point. But it's highly inappropriate to attempt to pressure the TC into making a quick decision using the *threat* of a GR. TC decisions take time precisely because they deal with nuanced issues that don't get handled any other way. Rushing to a vote only delays efforts to reach a consensus in the project, and is counter to the long-term health of Debian. I think a group of DDs are telling us that we're not doing our job in a timely fashion. While one may or may not agree with that, I think it's intended as constructive feedback, and personally I welcome the accountability to the rest of the project here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek vor...@debian.org writes: I will note for the record here that a number of DDs have at this point given the TC an ultimatum in private, stating that they will start a GR if the TC does not call for votes within a specified time limit. I suspect that this ultimatum didn't have much effect on Bdale's decision to call for a vote (since he was already predisposed to having the up/down vote in question). That is correct. I had already posted the call for votes on this ballot before I discovered that email in my inbox. I'm disappointed, particularly since you seem inclined to agree that the outcome of the simple part of this vote really isn't in question any more, that you've chosen to vote F first. That's certainly your right, but I do hope you will reconsider. Bdale pgpaMrJ0QsXFA.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek vor...@debian.org writes: I agree with Ian on this. At this point, it should be clear to everyone that, given the stated preferences of each member of the TC, the default init system for jessie will be systemd. Let's finish that vote then and move on. But I do not think this is the most important aspect of the problem that needs to be decided. The question of how, or if, multiple init systems will coexist in the Debian archive for jessie is what needs to be decided in order to unblock maintainers and give them clarity for their own packages. That is an entirely separate issue. I agree that it is important and needs to be resolved, but the Technical Committee is the wrong place to be designing this policy. We must (by 6.3.5) not engage in design of new proposals and policies. Yes, as individuals, we may choose to collaborate with others on the development of a suitable policy, and that group may well decide that they cannot reach a consensus and bring the issue back to the Technical Committee for advice. Please stop trying to bypass the constitutional process for policy design. -- keith.pack...@intel.com pgpO6TE2T0qde.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote: I agree with Ian on this. At this point, it should be clear to everyone that, given the stated preferences of each member of the TC, the default init system for jessie will be systemd. Without an official vote we can *not* say this. But I do not think this is the most important aspect of the problem that needs to be decided. Perhaps not, but it was the problem that was escelated to the TC The question of how, or if, multiple init systems will coexist in the Debian archive for jessie is what needs to be decided in order to unblock maintainers and give them clarity for their own packages. Why not let it to the maintainers to work through such issues, and resolve it in the TC when and if that process breaks down, like every other issue. The only thing that an up/down vote on init systems does is placate the crowds of onlookers who are not part of Debian's decision-making processes, at the expense of settling the more nuanced questions that need to be answered for the project. The more nuanced question was not asked of the TC This should not be our priority. Our purpose here is to make sound technical decisions on behalf of the project, not to preserve the TC's (or Debian's) reputation among third parties who have no legitimate say in the outcome. At this point, it's blocking folks inside Debian, who are stakeholders. It's not just the trolls of reddit and the internet, it's DDs who are annoyed there's no decision and integration work isn't started. We're less than a year from freeze. [snip] Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, 08 Feb 2014, Bdale Garbee wrote: - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I vote D U O V F. I also agree that given that while the additional questions of how packages are able to depend or rely on the default init system is important, it is not necessary to resolve that question to determine which system is going to be the default init system, as in no ballot yet has anyone changed their D/U ranking on the basis of which of the T, S, or L options were being voted for. -- Don Armstrong http://www.donarmstrong.com There is no form of lead-poisoning which more rapidly and thoroughly pervades the blood and bones and marrow than that which reaches the young author through mental contact with type metal. -- Oliver Wendell Holmes (Tilton 1947 p67) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee bd...@gag.com writes: - - - start ballot - - - We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be Dsystemd Uupstart Oopenrc Vsysvinit (no change) Frequires further discussion Should the project pass a General Resolution before the release of jessie asserting a position statement about issues of the day on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision. - - - end ballot - - - I vote: 1. D 2. U 3. O 4. V 5. F -- keith.pack...@intel.com pgpA7nr2PFtKo.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Keith Packard kei...@keithp.com writes: That is an entirely separate issue. I agree that it is important and needs to be resolved, but the Technical Committee is the wrong place to be designing this policy. We must (by 6.3.5) not engage in design of new proposals and policies. Well, in defense of the discussion that Steve, Colin, and I have been having, I do think it's worthwhile for the TC to try to hammer out a compromise on that point as well and express it as either technical advice to the project or as technical policy. While it may not have been explicitly listed in the message that referred this debate to the TC, the question of logind dependencies and the question of how to handle packages that no longer support a lowest-common-denominator sysvinit script have come up repeatedly in the interminable debian-devel discussions on this topic. I believe they're controversial questions and that we'd benefit from hashing out a reasonable approach in the TC context and offering it as advice. I also don't think that the approaches that we're discussing at the moment involve design work or are at all novel. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Russ Allbery r...@debian.org writes: Well, in defense of the discussion that Steve, Colin, and I have been having, I do think it's worthwhile for the TC to try to hammer out a compromise on that point as well and express it as either technical advice to the project or as technical policy. I'm really pleased that the three of you have constructed a policy that looks like a good compromise for this problem. I was worried that this would also become mired in controversy, when in fact there is already broad agreement and consensus. I also don't think that the approaches that we're discussing at the moment involve design work or are at all novel. It's not sophisticated or novel, but you're definitely crafting new policy for the project. Given that the group doing this are likely to reach consensus, it sounds like the Technical Committee process will not be necessary in this case. And I think we'll all be pleased if that happens. -- keith.pack...@intel.com pgpdtkz3TwzSq.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote: Keith Packard writes: That is an entirely separate issue. I agree that it is important and needs to be resolved, but the Technical Committee is the wrong place to be designing this policy. We must (by 6.3.5) not engage in design of new proposals and policies. Well, in defense of the discussion that Steve, Colin, and I have been having, I do think it's worthwhile for the TC to try to hammer out a compromise on that point as well and express it as either technical advice to the project or as technical policy. Why not hammer that out on -policy in public, and only if something goes wrong there, then defer it to the TC? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 05:46:07PM -0500, Paul Tagliamonte wrote: This should not be our priority. Our purpose here is to make sound technical decisions on behalf of the project, not to preserve the TC's (or Debian's) reputation among third parties who have no legitimate say in the outcome. At this point, it's blocking folks inside Debian, who are stakeholders. It's not just the trolls of reddit and the internet, it's DDs who are annoyed there's no decision and integration work isn't started. We're less than a year from freeze. Annoyed, yes. Blocked, no. There has never been anything blocking any Debian developer from doing work on improving the integration of systemd in Debian, on their own packages or on the packages of others. This has always been possible, without making systemd the default at all. If anyone *does* think they are blocked in doing this integration work because the default has not been decided, that can only be because of a misunderstanding of what deciding the default *means*. And that is precisely why I don't think it's good for the TC to send such an easily misinterpreted message by deciding the default without addressing the surrounding issues. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Michael Gilbert mgilb...@debian.org writes: On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote: Well, in defense of the discussion that Steve, Colin, and I have been having, I do think it's worthwhile for the TC to try to hammer out a compromise on that point as well and express it as either technical advice to the project or as technical policy. Why not hammer that out on -policy in public, and only if something goes wrong there, then defer it to the TC? Because -policy doesn't have a decision-making process other than consensus, so Ian's objections to all of the positions shy of L and my objections to L would deadlock and effectively block the -policy discussion from ever reaching a decision. There is no method for either of us to be overridden. Now, there would have been no way of knowing in advance that something like that would happen... but based on my past experience with Policy discussions and the level of controversy over this particular question, I would have been stunned if it hadn't happened, which is exactly why I would have immediately punted to the TC. Policy doesn't have a strong decision-making method other than consensus, which means that it will fail to arrive at a conclusion for anything that's even vaguely controversial (and sometimes even for things that are not very controversial but which don't inspire people to express an opinion). Maybe that's a bug that should be fixed, or maybe we should just use the TC as the way of reaching conclusions on controversial issues; I can see arguments either way. (The first Policy issue that I escalated to the TC as an experiment in using the TC to make these decisions was decided but was never implemented, and the second is still pending before the TC, so the track record here is not great, for a variety of reasons.) But as matters stand right now, there's no way for the Policy process to reach a conclusion on questions like this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 03:24:34PM -0800, Steve Langasek wrote: At this point, it's blocking folks inside Debian, who are stakeholders. It's not just the trolls of reddit and the internet, it's DDs who are annoyed there's no decision and integration work isn't started. We're less than a year from freeze. Annoyed, yes. Blocked, no. There has never been anything blocking any Debian developer from doing work on improving the integration of systemd in Debian, on their own packages or on the packages of others. This has always been possible, without making systemd the default at all. I understand you think that, and I empathize, but I disagree. The fact is, I have limited time. If I'm going to focus on making a bigger impact with my work, I'm going to stick to dealing with issues that effect the most users. I don't care about the init system all that much, in the end, it's not important. I do care about ensuring we have something maintainable and stable. As soon as we settle which init system is default (and by a rough count, I believe this issue is resolved now, thank you TC :) ), I can start spending time on ensuring we have a polished distro throughout this change by testing, and contributing patches when I hit issues that I have time to fix. I think this is the norm. I assure you it was not only annoying, but also blocking. If anyone *does* think they are blocked in doing this integration work because the default has not been decided, that can only be because of a misunderstanding of what deciding the default *means*. I don't grok. Default means it's going to be used by all users unless they're technical enough to change it, in which case, I care slighly less, since they're able to fix it and provide patches when they hit issues. And that is precisely why I don't think it's good for the TC to send such an easily misinterpreted message by deciding the default without addressing the surrounding issues. I understand why you might think that, but I believe it to not be entirely in-line with how many view the situation. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote: Michael Gilbert writes: Why not hammer that out on -policy in public, and only if something goes wrong there, then defer it to the TC? Because -policy doesn't have a decision-making process other than consensus, so Ian's objections to all of the positions shy of L and my objections to L would deadlock and effectively block the -policy discussion from ever reaching a decision. There is no method for either of us to be overridden. But at least it would follow the usual process, and only when consensus does actually fail does the TC need to mediate. There would also presumably be proposed diffs to the policy text from both sides for the TC to review, and decide among the options, and that would be far more nuanced than this or that init as currently proposed. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Paul Tagliamonte paul...@debian.org writes: As soon as we settle which init system is default (and by a rough count, I believe this issue is resolved now, thank you TC :) ) It's not. All ballot options have to have a majority above FD in order to be eligible to win the ballot. At least one more person has to vote another option above FD for there to be a winner other than FD. If all remaining TC members vote FD first, FD wins. That would be the way of indicating support for Ian's position that we should not hold independent votes. If all remaining TC members other than one vote FD first and the remaining one votes something else first, that option wins, since our resolution method fails later-no-harm spectacularly. As Steve points out, all those who have voted so far have voted in explicit disregard to this possibility. I did so on the grounds that I refuse to vote tactically at that level, and it sounds like Steve is of a similar feeling. FWIW, that's also why I want to vote the issues separately, since it avoids a giant tactical morass. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On 08/02/14 23:24, Steve Langasek wrote: There has never been anything blocking any Debian developer from doing work on improving the integration of systemd in Debian, on their own packages or on the packages of others. OTOH I'm eagerly awaiting the TC's decision[s] because it will likely influence the direction of the non-Linux ports. If Upstart had won somehow, most people working on GNU/kFreeBSD seemed willing to adopt it on those grounds. But it no longer seems the likely choice for GNU/Linux. And assuming systemd wins, a policy decision on dependencies and level of coupling may lead to ports either supporting or dropping certain packages, or a whole desktop environment. IMHO it was a little frustrating that Ian's ballot couldn't go ahead last week and reach a consensus on both issues. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: call for votes on default Linux init system for jessie
Michael Gilbert mgilb...@debian.org writes: On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote: Because -policy doesn't have a decision-making process other than consensus, so Ian's objections to all of the positions shy of L and my objections to L would deadlock and effectively block the -policy discussion from ever reaching a decision. There is no method for either of us to be overridden. But at least it would follow the usual process, and only when consensus does actually fail does the TC need to mediate. If you're looking for Policy Editors who enjoy running things through a process that won't be successful just so that we can say they've been run through a process, you're going to need someone other than me. I find that sort of thing to be tedious in the extreme and a giant waste of everyone's time. I have about four thousand things I could be working on in Debian that would be more useful than going through that exercise. There would also presumably be proposed diffs to the policy text from both sides for the TC to review, and decide among the options, and that would be far more nuanced than this or that init as currently proposed. I certainly hope that no one would spend lots of time drafting wording without some broad agreement on what we wanted to say. It's rare that the question really rests on some point of minor nuance or phrasing; it's better to hash out rough, broad statements until we get to some general point of agreement and then work on diffs. Otherwise, again, you run the risk of wasting a bunch of people's time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Steven Chamberlain ste...@pyro.eu.org writes: IMHO it was a little frustrating that Ian's ballot couldn't go ahead last week and reach a consensus on both issues. I would be very interested in your comments, from the perspective of a non-Linux port maintainer, on the language that Steve and I have been discussing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
El Sat, 8 de Feb 2014 a las 3:48 PM, Russ Allbery r...@debian.org escribió: Paul Tagliamonte paul...@debian.org writes: As soon as we settle which init system is default (and by a rough count, I believe this issue is resolved now, thank you TC :) ) It's not. All ballot options have to have a majority above FD in order to be eligible to win the ballot. At least one more person has to vote another option above FD for there to be a winner other than FD. If all remaining TC members vote FD first, FD wins. That would be the way of indicating support for Ian's position that we should not hold independent votes. I think it moreso indicates that if there are separate votes, that the init system choice can not be first. I do wonder, how many TC members would support voting on GR, then on T/L (or whatever it is you, Colin, and Steve are working on), then on the init system? -- Cameron Norman
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote: I understand you think that, and I empathize, but I disagree. The fact is, I have limited time. If I'm going to focus on making a bigger impact with my work, I'm going to stick to dealing with issues that effect the most users. I don't care about the init system all that much, in the end, it's not important. I do care about ensuring we have something maintainable and stable. Why bring such a controversial and polarizing issue before the TC if the outcome doesn't matter much to you? sysvinit is maintainable and stable, so why seek to change it? Paul, you know I think you're awesome, but you've stirred up a whole lot of trouble here with a questionable motive. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
El Sat, 8 de Feb 2014 a las 3:56 PM, Michael Gilbert mgilb...@debian.org escribió: On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote: I understand you think that, and I empathize, but I disagree. The fact is, I have limited time. If I'm going to focus on making a bigger impact with my work, I'm going to stick to dealing with issues that effect the most users. I don't care about the init system all that much, in the end, it's not important. I do care about ensuring we have something maintainable and stable. Why bring such a controversial and polarizing issue before the TC if the outcome doesn't matter much to you? sysvinit is maintainable and stable, so why seek to change it? Perhaps the movement in GNOME to depend on a number of systemd provided interfaces has led Paul to believe that sysvinit is unmaintainable? AFAIR, systemd-shim was not available when he presented the question to the TC (or am I mistaken?). -- Cameron
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote: But at least it would follow the usual process, and only when consensus does actually fail does the TC need to mediate. If you're looking for Policy Editors who enjoy running things through a process that won't be successful just so that we can say they've been run through a process, you're going to need someone other than me. I find that sort of thing to be tedious in the extreme and a giant waste of everyone's time. I have about four thousand things I could be working on in Debian that would be more useful than going through that exercise. That's only true if someone does actually get in the way. There may actually be a clear path to consensus at this point, given that you already seem to have people from both D and U sides apparently agreeing in private. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Michael Gilbert mgilb...@debian.org writes: On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote: If you're looking for Policy Editors who enjoy running things through a process that won't be successful just so that we can say they've been run through a process, you're going to need someone other than me. I find that sort of thing to be tedious in the extreme and a giant waste of everyone's time. I have about four thousand things I could be working on in Debian that would be more useful than going through that exercise. That's only true if someone does actually get in the way. There may actually be a clear path to consensus at this point, given that you already seem to have people from both D and U sides apparently agreeing in private. There aren't any private discussions about the T and L options between TC members that aware of, for whatever it's worth. All the discussion is here on the bug. We got to a place where we're hammering out something we're all happy with only in the context of a decision-making process and two failed votes, and only by discussing options that one of the parties to the discussion has explicitly rejected as unacceptable. Look, I've been involved in Policy work for years now. I think I have a pretty good intuition for what sort of questions can be dealt with usefully in that framework and which ones can't. You're certainly entitled to think that I'm wrong, but it's unlikely that I'm going to change my mind on this particular question, since I don't think it's even close. It's hard to avoid the feeling that you'd rather not have the TC discuss this question since the TC is arriving at a conclusion that you don't like. That's understandable, but I don't think the results are going to be any more to your liking regardless of the forum, whether it be the TC, a GR, or Policy. I certainly don't believe, after having waded through most of the debian-devel threads on the topic, that the project was going to suddenly realize that everyone had good points and arrive at an amicable consensus. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 03:53:40PM -0800, Russ Allbery wrote: Steven Chamberlain ste...@pyro.eu.org writes: IMHO it was a little frustrating that Ian's ballot couldn't go ahead last week and reach a consensus on both issues. I would be very interested in your comments, from the perspective of a non-Linux port maintainer, on the language that Steve and I have been discussing. FWIW, it occurred to me about a week ago that, although we've been discussing a question that has implications for all of Debian ports (even if the current ballot only considers the Linux ports), at no time has the TC actually asked the Hurd and FreeBSD porters for input - aside from those who have found their own way to this bug. Considering that some of the discussions have made assumptions about what the porters will be inclined to implement given a particular decision by the TC, I think this is an oversight that we should correct by explicitly reaching out to the porter lists. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 7:17 PM, Russ Allbery wrote: Look, I've been involved in Policy work for years now. I think I have a pretty good intuition for what sort of questions can be dealt with usefully in that framework and which ones can't. You're certainly entitled to think that I'm wrong, but it's unlikely that I'm going to change my mind on this particular question, since I don't think it's even close. It's hard to avoid the feeling that you'd rather not have the TC discuss this question since the TC is arriving at a conclusion that you don't like. It's not that I dislike any particular conclusion, it is that I dislike the apparent rush toward conclusion. The TC is a deliberative body that is only supposed to act when all normal means have been exhausted. The fact that no policy discussion ever happened means that something has really going wrong here. I'd be happy to see a change post-jessie, but I feel like it is a self-imposed rush to push anything through for jessie. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
]] Steve Langasek Annoyed, yes. Blocked, no. There has never been anything blocking any Debian developer from doing work on improving the integration of systemd in Debian, on their own packages or on the packages of others. This has always been possible, without making systemd the default at all. It seems a bit pointless to start doing the work on how to change the default to systemd until that was actually decided. Once we have a decision (and assuming that the default will be systemd), I was planning on starting at looking at how to best do the transition. So maybe not blocked as such, but «annoyed and unwilling to spend effort that might be wasted». -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote: Why bring such a controversial and polarizing issue before the TC if the outcome doesn't matter much to you? OK, phrased badly. I don't care what it is, so long as it's not sysvinit :) I believe it to be broken, and not a future-proof solution, and I assumed that was sorta taken for granted that others agreed. The general consensus[0] is that sysvinit is not a solution going forward. sysvinit is maintainable and stable, so why seek to change it? It's stable, but it's not going to be maintainable in the long-run, and I believe it will become unmaintainable very soon. Paul, you know I think you're awesome, but you've stirred up a whole lot of trouble here with a questionable motive. What motive is that, if I might ask?[1] :) We were already flaming pretty hard, it was out of control, it was in the best interest of everyone to get it resolved in a quick way. I believed (and still believe) the TC was the best way out of the situation, so I did the natrual thing. I care in so far as we are able to keep Debian maintainable and use software that allows future releases[2] to get sent to users without fuss. Best wishes, Mike Much love, Paul [0]: Yes, I know tg disagrees. [1]: Assuming ill intent are we? [2]: of Debian itself and new upstream releases (say, GNOME) -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 9:08 PM, Paul Tagliamonte wrote: On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote: Paul, you know I think you're awesome, but you've stirred up a whole lot of trouble here with a questionable motive. What motive is that, if I might ask?[1] :) [1]: Assuming ill intent are we? Not my intent to give that impression at all. I know you have the best of intentions, but the phrasing of the question posed lead the TC in a very specific high controversy direction. I think it would have been better to ask for some smaller less controversial decisions solving existing known init system related problems (like logind), and once enough of those were decided, it would probably be abundantly clear which default the init should change to. Instead, none of the important implementation related stuff has been discussed. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Sat, Feb 8, 2014 at 9:23 PM, Michael Gilbert wrote: Instead, none of the important implementation related stuff has been discussed. Correction, a lot of that has been discussed, but there has been no progress on it due to the distraction on the bigger political problem. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On 9 February 2014 09:52, Russ Allbery r...@debian.org wrote: If you're looking for Policy Editors who enjoy running things through a process that won't be successful just so that we can say they've been run through a process, you're going to need someone other than me. In that case, wouldn't it make sense to have a quick chat with the other policy editors about officially delegating the task of deciding on policy for depending on init systems to the tech ctte? Could even open a new bug for it! Cheers, aj -- Anthony Towns a...@erisian.com.au -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Anthony Towns writes (Bug#727708: call for votes on default Linux init system for jessie): On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote: On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote: Q2: Is it OK for packages to depend on a specific init system as pid 1 ? Q2a: Is it OK for packages providing init systems to provide other APIs beyond just the minimum needed for starting/stopping services? We might disagree on the extent, perhaps, but I doubt anyone on the committee would vote against this in its general form; This just goes to show how the exact form of words used can be confusing or misleading. So looking at the votes today, I would have said that both Ian and Andi's original votes are against this (ranking the options which allow specifying a dependency on a specific init below further discussion), and probably Steve's does too, although I assume that's more an objection against the wording. At least, the impact seems like it is: - init systems can provide whatever extra APIs they like - other packages can only use extra APIs if they have a dependency on the providing package - packages may not depend on specific init systems * therefore packages cannot use the extra APIs (In the L options:) Yes, packages which aren't part of the init system aren't allowed to depend on those extra APIs. But packages which _are_ part of the init system are so allowed. (Think, for example, management guis or addons for a particular init system.) Answering no to the question Q2a above would have forbidden that. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson wrote: Anthony Towns writes (Bug#727708: call for votes on default Linux init system for jessie): So looking at the votes today, I would have said that both Ian and Andi's original votes are against this (ranking the options which allow specifying a dependency on a specific init below further discussion), and probably Steve's does too, although I assume that's more an objection against the wording. At least, the impact seems like it is: - init systems can provide whatever extra APIs they like - other packages can only use extra APIs if they have a dependency on the providing package - packages may not depend on specific init systems * therefore packages cannot use the extra APIs (In the L options:) Yes, packages which aren't part of the init system aren't allowed to depend on those extra APIs. But packages which _are_ part of the init system are so allowed. (Think, for example, management guis or addons for a particular init system.) Answering no to the question Q2a above would have forbidden that. That is a very interesting clarification, and not one that seems at all obvious from the text of 'L'. 'L' talks about Software outside of an init system's implementation, which does not seem like it would extend to management guis or addons. So, for instance, GNOME Logs, a new upstream project specifically designed to browse the systemd journal, could by the clarification above be considered part of the init system, and thus can depend on it? If so, I would be very interested in further clarifications regarding what it takes to be considered part of an init system. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Josh Triplett writes (Bug#727708: call for votes on default Linux init system for jessie): That is a very interesting clarification, and not one that seems at all obvious from the text of 'L'. 'L' talks about Software outside of an init system's implementation, which does not seem like it would extend to management guis or addons. I think it depends what you think of as an init system's implementation. I would include the utilities you use to manage it. So, for instance, GNOME Logs, a new upstream project specifically designed to browse the systemd journal, could by the clarification above be considered part of the init system, and thus can depend on it? I haven't looked at that in detail. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Hey Colin, On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote: On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote: Q2: Is it OK for packages to depend on a specific init system as pid 1 ? Q2a: Is it OK for packages providing init systems to provide other APIs beyond just the minimum needed for starting/stopping services? We might disagree on the extent, perhaps, but I doubt anyone on the committee would vote against this in its general form; So looking at the votes today, I would have said that both Ian and Andi's original votes are against this (ranking the options which allow specifying a dependency on a specific init below further discussion), and probably Steve's does too, although I assume that's more an objection against the wording. At least, the impact seems like it is: - init systems can provide whatever extra APIs they like - other packages can only use extra APIs if they have a dependency on the providing package - packages may not depend on specific init systems * therefore packages cannot use the extra APIs Cheers, aj -- Anthony Towns a...@erisian.com.au -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Anthony Towns wrote: On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote: On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote: Q2: Is it OK for packages to depend on a specific init system as pid 1 ? Q2a: Is it OK for packages providing init systems to provide other APIs beyond just the minimum needed for starting/stopping services? We might disagree on the extent, perhaps, but I doubt anyone on the committee would vote against this in its general form; So looking at the votes today, I would have said that both Ian and Andi's original votes are against this (ranking the options which allow specifying a dependency on a specific init below further discussion), and probably Steve's does too, although I assume that's more an objection against the wording. At least, the impact seems like it is: - init systems can provide whatever extra APIs they like - other packages can only use extra APIs if they have a dependency on the providing package - packages may not depend on specific init systems * therefore packages cannot use the extra APIs I agree with your conclusion on the practical effect here. I'm also amused that exactly the same logic readily applies at the next level down, to an init system making use of APIs and functionality that Linux has and other systems do not. In both cases, the question is the same: least common denominator, or actually using available functionality? (To forestall the obvious objection: optional is the same as least common denominator, in that it effectively prevents *relying* on that functionality, and thus forces the creation of a least-common-denominator fallback, which everything higher in the stack must then cope with.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote: Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. I agree with this; I don't think we should try to force developers into significant work to satisfy an init system constraint as that may prevent or delay important fixes and improvements from entering the repository. Of course, nothing would prevent someone else from fixing these kinds of bugs and having those fixes get merged into the package, potentially invoking §6.1.4 to have the tech-ctte resolve any conflict as needed. However, I'd anticipate that most package developers would readily accept fixes that made their packages work for more people. I'd like to believe this; however, the fact that bug #726763 is still open leads me to fear otherwise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: call for votes on default Linux init system for jessie
Steve Langasek wrote: On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote: Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. I agree with this; I don't think we should try to force developers into significant work to satisfy an init system constraint as that may prevent or delay important fixes and improvements from entering the repository. Of course, nothing would prevent someone else from fixing these kinds of bugs and having those fixes get merged into the package, potentially invoking §6.1.4 to have the tech-ctte resolve any conflict as needed. However, I'd anticipate that most package developers would readily accept fixes that made their packages work for more people. I'd like to believe this; however, the fact that bug #726763 is still open leads me to fear otherwise. I don't see any counterexamples in 726763 to the statement that nothing would prevent someone else from fixing these kinds of bugs and having those fixes get merged into the package, or to the statement that most package developers would readily accept fixes that made their packages work for more people. Fixing 726763 just needs a Depends from the GNOME packages to reflect their dependency on logind and the suspend inhibit mechanism, which as stated in the bug log won't happen until the resolution of 727708. Meanwhile, installing either systemd-sysv or systemd-shim (or having systemd installed and booting with init=/bin/systemd) fixes the issue reported in 726763. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
(I was informed, that my posts are not welcome anymore here. So, there is last one for all.) On Thu, Jan 30, 2014 at 12:05:19PM -0700, Bdale Garbee wrote: Sergey B Kirpichev skirpic...@gmail.com writes: I just wonder why nobody from tect-ctte take care about the exact specification of that bare minimum (or, in other words, what exactly is wrong with sysvinit). In a sense, we all have done this, even if you don't see it explicitly written in just this way. Sorry. Maybe it's clear from the thread for others, that this specification is somewhere in minds of all tech-ctte members... But I doubt if it's so, as I was kindly pointed out to https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv Is this all (what we want to fix in sysvinit/what we want to have in the modern init)? And that wasn't clear for others, otherwise I can't explain, for example, the questions why OpenRC was silently discarded from reviews. The thing that may not be obvious is that this line doesn't stand still, it is constantly moving as more people develop more free software that does newer and better things and in the process builds new dependencies. Old init was working for years. Are we only buy something that satisfy the new dependencies (for the Gnome) or a new init, that would work for comparable time? On Thu, Jan 30, 2014 at 05:16:46PM -0800, Keith Packard wrote: In effect, X takes the Debian position that patches which improve interoperabilty with a specific init system should be integrated. Seems to be sane and reasonable position. I wonder why Gnome people can't follow this. Where is the list of problems for sysvinit we intend to solve? For X, the problem is running X as a user other than root (There are sysvinit-enabled setups even without X...) On Fri, Jan 31, 2014 at 09:38:45AM +0100, Josselin Mouette wrote: https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv Since you forgot to paste the first sentence, let me add it here. “Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.” I'm not forgot, because it's not the only reason - please see the mentioned example. Anyone who knows how Linux works doesn’t consider sysvinit a viable choice today. I'm sure Google sysadmins know how Linux works, still they consider sysvinit to be a viable (and preferred) choice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Wed, Jan 29, 2014 at 11:13:33AM +, Colin Watson wrote: We might disagree on the extent, perhaps, but I doubt anyone on the committee would vote against this in its general form; both systemd and upstart implement interfaces beyond the bare minimum, though upstart certainly takes a more minimalist tack. I just wonder why nobody from tect-ctte take care about the exact specification of that bare minimum (or, in other words, what exactly is wrong with sysvinit). Correct me, please, if I'm wrong. The whole 3000+ thread is about different features of one or another sysvinit replacement. Or do we buy the least terrible variant from the submitted? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Sergey B Kirpichev skirpic...@gmail.com writes: I just wonder why nobody from tect-ctte take care about the exact specification of that bare minimum (or, in other words, what exactly is wrong with sysvinit). In a sense, we all have done this, even if you don't see it explicitly written in just this way. The thing that may not be obvious is that this line doesn't stand still, it is constantly moving as more people develop more free software that does newer and better things and in the process builds new dependencies. Bdale pgpqP6Nkr5vW9.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote: On 28 January 2014 21:39, Ian Jackson ijack...@chiark.greenend.org.uk wrote: I don't want to pass a resolution specifying the default without also answering the other two, related, contentious questions: Q1: Do we intend to support multiple systems long-term, or do we intend to settle on a single system, probably in jessie+1 ? FWIW, that seems overly prescriptive to me -- if we settle on systemd now, and as a result upstart stops getting maintained and systemfree gets written that uses the same config files but only works on FreeBSD and Hurd, maybe no one will want to maintain multiple init systems later. Perhaps a better phrasing would be something like remain open to supporting multiple init systems as long as they are actively maintained. Conversely, maybe people get excited about some init system we don't pick as default for jessie and it becomes really awesome by the time jessie is out; why would we want to prevent it being available in Debian even if it's not ready to be default, or doesn't work with Gnome yet, or whatever? (I don't think I can suggest better wording for the single options as they aren't ones I favour.) Q2: Is it OK for packages to depend on a specific init system as pid 1 ? I don't think that's the right question for the issue(s) at play here. From what I can tell, the important question isn't whether systemd or upstart happens to be pid 1, but rather whether certain interfaces (dbus, logind, potentially others) that are only (currently) provided by systemd are available on the system. That's certainly the principal issue for e.g. GNOME. But I think it's reasonable to anticipate that some maintainers might want to drop support in their service packages for init systems which they don't favour and which aren't the default; one can reasonably take different views on whether that's appropriate, and I think guidance from the committee would be useful. I agree with you that it's worth breaking it down into the matters of service specifications (which for the most part have resisted attempts to implement translation layers) and other APIs (which have a better track record here). Q2a: Is it OK for packages providing init systems to provide other APIs beyond just the minimum needed for starting/stopping services? We might disagree on the extent, perhaps, but I doubt anyone on the committee would vote against this in its general form; both systemd and upstart implement interfaces beyond the bare minimum, though upstart certainly takes a more minimalist tack. After Steve's and Russ's comments in [0] and [1], and thinking about it some more, I'm inclined to think all those questions could reasonably be dealt with through the policy process, though I still think some non-binding advice from the tech ctte wouldn't be out of place. I certainly don't think we should get into the specifics of how things should be laid out, but the general direction is non-obvious and important. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote: On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote: For anyone intending to make Debian the laughingstock of the open source world, here is a good opportunity: Debian decides that Upstart is the default init system for jessie, but it's default desktop GNOME forces the installation of systemd. What makes you think gnome is going to be the default? http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5 Read the text in debian/changelog that is there - the final decision will be made in August (or later). I was sarcastically describing a worst-case scenario that is not completely impossible - in reality I would expect enough sanity in Debian to ensure that something depending on a non-default init system cannot be part of a default installation. Best wishes, Mike cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On 19:01, Adrian Bunk wrote: On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote: What makes you think gnome is going to be the default? http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5 Read the text in debian/changelog that is there - the final decision will be made in August (or later). I was sarcastically describing a worst-case scenario that is not completely impossible - in reality I would expect enough sanity in Debian to ensure that something depending on a non-default init system cannot be part of a default installation. I'd expect Debian GNOME install media would still give a GNOME desktop by default, Debian KDE disc gives you KDE, etc. Would it be crazy to suggest putting the preferred init system in the 'task'? A Debian GNOME install would likely install systemd, otherwise it could be something else. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee writes (call for votes on default Linux init system for jessie): The default init system for Linux architectures in jessie should be 1. systemd 2. upstart 3. openrc 4. sysvinit (no change) 5. requires further discussion. It looks like this is going to be voted down or withdrawn, thanks, and everyone is agreed that there should be a rider about GRs. I'll therefore comment on the substance. I don't want to pass a resolution specifying the default without also answering the other two, related, contentious questions: Q1: Do we intend to support multiple systems long-term, or do we intend to settle on a single system, probably in jessie+1 ? Q2: Is it OK for packages to depend on a specific init system as pid 1 ? There are two reasons why I want to decide these questions in the same vote. Firstly, as I have said, TC members should be able to express the preference only X, X by default but also others, Y by default but also others, Y, which is a perfectly reasonable one but which cannot be expressed by a concurrent ballots (and holding the ballots sequentially in situations like this can be a way of manipulating the result). Secondly, making a decision on the default without clearly stating a requirement for support for multiple systems risks a situation where partisans for the winning system create facts on the ground which make it difficult to support multiple systems. I think there are the following three reasonable answers to Q1/Q2 taken together. i. Q1: Multiple in jessie Q2: Requiring specific init is forbidden ii. Q1: Multiple in jessie Q2: Requiring default init is permitted iii. Q1: Single in jessie+1 Q2: Requiring default init is permitted Of these (ii) would cause the non-default inits to rot. Unless anyone thinks this is a useful option I don't think we should vote on it. So that leaves my text from yesterday: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. vs something like: O. Debian intends to converge on one init system; in jessie+1, packages may require that the default init system is in use. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson writes (Bug#727708: call for votes on default Linux init system for jessie): Bdale Garbee writes (call for votes on default Linux init system for jessie): The default init system for Linux architectures in jessie should be D. systemd U. upstart R. openrc V. sysvinit (no change) F. requires further discussion. I have lettered these. So that leaves my text from yesterday: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. (I forgot to say, I edited that a bit.) vs something like: O. Debian intends to converge on one init system; in jessie+1, packages may require that the default init system is in use. If we are I to vote now, I would like to see on the ballot at least: DM systemd by default, but also others DO systemd only in jessie+1 UM upstart by default, but also others UO upstart only in jessie+1 RM openrc by default, but also others VM sysvinit by default, but also others I don't think RO and VO make much sense. Does my text for O correctly represent the views of those who want us to converge on a single system ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson writes (Re: Bug#727708: call for votes on default Linux init system for jessie): So that leaves my text from yesterday: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. (I forgot to say, I edited that a bit.) I hope this rephrasing is good enough to satisfy the quibbles which come up every time about this. If any of the TC members feel that there is a better way to put this requirement I would be happy to hear it. For the avoidance of doubt, this is to be fleshed out into policy where the details can be dealt with. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, 28 Jan 2014, Ian Jackson wrote: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. I still don't think the last sentence of this paragraph completely handles the cases where someone can legitimately depend on a specific init system or specific init system interface. If we're supporting multiple init systems, then software which doesn't support multiple init systems which could feasibly do so is buggy. If patches to fix it appear and aren't applied, then people can appeal to the CTTE. It's not necessary or feasible for us to anticipate every single technical wrinkle and delay making a decision to do so. -- Don Armstrong http://www.donarmstrong.com Taxes are not levied for the benefit of the taxed. -- Robert Heinlein _Time Enough For Love_ p250 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, 28 Jan 2014, Ian Jackson wrote: Q1: Do we intend to support multiple systems long-term, or do we intend to settle on a single system, probably in jessie+1 ? Q2: Is it OK for packages to depend on a specific init system as pid 1 ? [...] Firstly, as I have said, TC members should be able to express the preference only X, X by default but also others, Y by default but also others, Y, which is a perfectly reasonable one but which cannot be expressed by a concurrent ballots The only reason to interlink these questions is if the ordering of someone's preference on the init system question is dependent on their preference on these two questions. If that's the case, then whoever feels that way should propose a draft which includes an option which handles that particular case. Secondly, making a decision on the default without clearly stating a requirement for support for multiple systems risks a situation where partisans for the winning system create facts on the ground which make it difficult to support multiple systems. This presupposes bad faith, and even if it were so, such behavior would still be possible even if we voted in a single decision. -- Don Armstrong http://www.donarmstrong.com The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Don Armstrong writes (Bug#727708: call for votes on default Linux init system for jessie): On Tue, 28 Jan 2014, Ian Jackson wrote: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. I still don't think the last sentence of this paragraph completely handles the cases where someone can legitimately depend on a specific init system or specific init system interface. Would you care to suggest an alternative wording ? If we're supporting multiple init systems, then software which doesn't support multiple init systems which could feasibly do so is buggy. If patches to fix it appear and aren't applied, then people can appeal to the CTTE. It's not necessary or feasible for us to anticipate every single technical wrinkle and delay making a decision to do so. I agree with this. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 8:51 AM, Don Armstrong wrote: On Tue, 28 Jan 2014, Ian Jackson wrote: Q1: Do we intend to support multiple systems long-term, or do we intend to settle on a single system, probably in jessie+1 ? Q2: Is it OK for packages to depend on a specific init system as pid 1 ? [...] Firstly, as I have said, TC members should be able to express the preference only X, X by default but also others, Y by default but also others, Y, which is a perfectly reasonable one but which cannot be expressed by a concurrent ballots The only reason to interlink these questions is if the ordering of someone's preference on the init system question is dependent on their preference on these two questions. If that's the case, then whoever feels that way should propose a draft which includes an option which handles that particular case. Secondly, making a decision on the default without clearly stating a requirement for support for multiple systems risks a situation where partisans for the winning system create facts on the ground which make it difficult to support multiple systems. This presupposes bad faith, and even if it were so, such behavior would still be possible even if we voted in a single decision. Even if the TC acts with the purest of motives, there is always a certain subset of observers likely to assume the worst and ascribe a bad faith motive. It is better to head that off by making the TCs intention and thought process abundantly clear. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: If we are I to vote now, I would like to see on the ballot at least: If we choose to proceed with this kind of a vote, the combinations I care about are adequately captured by this list. I remain uncomfortable, however, about trying to be prescriptive about what happens past jessie. Bdale pgpVSHEGpytXv.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think there are the following three reasonable answers to Q1/Q2 taken together. i. Q1: Multiple in jessie Q2: Requiring specific init is forbidden ii. Q1: Multiple in jessie Q2: Requiring default init is permitted iii. Q1: Single in jessie+1 Q2: Requiring default init is permitted Why do you use 'specific init' in (1) but default init in (ii) and (iii)? Please be consistent in the use of specific init for all three options. With that change, (ii) might well be my first choice among these three. As written, I don't see the point of having Q2 included in (iii) other than for completeness, as asserting that we'll only support one init system seems to make the question of whether anything depends on it explicitly irrelevant and/or redundant? Bdale pgp5H9t2ySf1g.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee writes (Re: Bug#727708: call for votes on default Linux init system for jessie): Ian Jackson ijack...@chiark.greenend.org.uk writes: I think there are the following three reasonable answers to Q1/Q2 taken together. i. Q1: Multiple in jessie Q2: Requiring specific init is forbidden ii. Q1: Multiple in jessie Q2: Requiring default init is permitted iii. Q1: Single in jessie+1 Q2: Requiring default init is permitted Why do you use 'specific init' in (1) but default init in (ii) and (iii)? Please be consistent in the use of specific init for all three options. I think it doesn't make sense to allow people to require a non-default init. If you think it does then there are three possible answers to Q2: requiring a specific init is permitted even if it is not the default one, requiring the default init is OK but requiring another is not and requiring a specific init is not OK. With that change, (ii) might well be my first choice among these three. But I guess you disagree. As written, I don't see the point of having Q2 included in (iii) other than for completeness, as asserting that we'll only support one init system seems to make the question of whether anything depends on it explicitly irrelevant and/or redundant? I was trying to determine the reasonable subset of the entire possible matrix of answers. Obviously I think the answer single to Q1 implies the requiring the default init is OK to Q2. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it doesn't make sense to allow people to require a non-default init. If you think it does then there are three possible answers to Q2: requiring a specific init is permitted even if it is not the default one, requiring the default init is OK but requiring another is not and requiring a specific init is not OK. I prefer Don's approach to thinking about this: I still don't think the last sentence of this paragraph completely handles the cases where someone can legitimately depend on a specific init system or specific init system interface. If we're supporting multiple init systems, then software which doesn't support multiple init systems which could feasibly do so is buggy. If patches to fix it appear and aren't applied, then people can appeal to the CTTE. It's not necessary or feasible for us to anticipate every single technical wrinkle and delay making a decision to do so. Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. Bdale pgpSYduCPd2us.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it doesn't make sense to allow people to require a non-default init. I think this position is consistent with allowing each maintainer broad autonomy, and not overly burdening them with requirements that may make it difficult or impossible to provide bug fixes and other improvements From newer upstream versions. Yes, I'd consider it a bug, but I'm not sure it reaches the level of an RC bug. -- keith.pack...@intel.com pgpHYnPhATDnO.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. I agree with this; I don't think we should try to force developers into significant work to satisfy an init system constraint as that may prevent or delay important fixes and improvements from entering the repository. Of course, nothing would prevent someone else from fixing these kinds of bugs and having those fixes get merged into the package, potentially invoking §6.1.4 to have the tech-ctte resolve any conflict as needed. However, I'd anticipate that most package developers would readily accept fixes that made their packages work for more people. -- keith.pack...@intel.com pgpOkg9iXeHoZ.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: If we are I to vote now, I would like to see on the ballot at least: DM systemd by default, but also others DO systemd only in jessie+1 UM upstart by default, but also others UO upstart only in jessie+1 RM openrc by default, but also others VM sysvinit by default, but also others I'm still very uncomfortable with any vote that would constrain our solution space past the Jessie release. I'm fairly convinced that we'll be supporting multiple init systems for a long time, but my vision gets very fuzzy out that far, and it's just possible I might be wrong. -- keith.pack...@intel.com pgpf09RamrGIf.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 11:39:51AM +, Ian Jackson wrote: ... M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. ... Is udev considered to be part of systemd's implementation? Ian. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 09:12:54AM -0800, Keith Packard wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it doesn't make sense to allow people to require a non-default init. I think this position is consistent with allowing each maintainer broad autonomy, and not overly burdening them with requirements that may make it difficult or impossible to provide bug fixes and other improvements From newer upstream versions. Yes, I'd consider it a bug, but I'm not sure it reaches the level of an RC bug. For anyone intending to make Debian the laughingstock of the open source world, here is a good opportunity: Debian decides that Upstart is the default init system for jessie, but it's default desktop GNOME forces the installation of systemd. Ian. cu Adrian BTW: Yes, the default desktop for jessie discussion that is scheduled for August is also intertwingled with the init system issue... -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie [and 1 more messages]
Bdale Garbee writes (Bug#727708: call for votes on default Linux init system for jessie): Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. Keith Packard writes (Bug#727708: call for votes on default Linux init system for jessie): I'm still very uncomfortable with any vote that would constrain our solution space past the Jessie release. I'm fairly convinced that we'll be supporting multiple init systems for a long time, but my vision gets very fuzzy out that far, and it's just possible I might be wrong. I'm not going to try to talk you out of this. In that case we need options on the ballot which don't contain any of the texts on this question I was proposing, as well as options why do. If there is noone who wants to explicitly say something like this O. Debian intends to converge on one init system; in jessie+1, packages may require that the default init system is in use. then there is no point putting it on the ballot. That would leave us with DM systemd by default, but also others D- systemd by default, say nothing else UM upstart by default, but also others U- upstart by default, say nothing else R- openrc by default, say nothing else V- sysvinit by default, say nothing else I'm not going to push for RM and RV even though I would prefer them, because I think R- and V- are more popular in the rest of the TC. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Don Armstrong writes (Bug#727708: call for votes on default Linux init system for jessie): On Tue, 28 Jan 2014, Ian Jackson wrote: M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. I still don't think the last sentence of this paragraph completely handles the cases where someone can legitimately depend on a specific init system or specific init system interface. If we're supporting multiple init systems, then software which doesn't support multiple init systems which could feasibly do so is buggy. If patches to fix it appear and aren't applied, then people can appeal to the CTTE. It's not necessary or feasible for us to anticipate every single technical wrinkle and delay making a decision to do so. Is there some rephrasing of this paragraph which would persuade you to put it ahead of a ballot option with the paragraph entirely deleted ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: call for votes on default Linux init system for jessie
Adrian Bunk b...@stusta.de writes: Debian decides that Upstart is the default init system for jessie, but it's default desktop GNOME forces the installation of systemd. There are reasons I've left gnome behind... -- keith.pack...@intel.com pgpplPgi_3rkN.pgp Description: PGP signature
Bug#727708: call for votes on default Linux init system for jessie
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think there are the following three reasonable answers to Q1/Q2 taken together. i. Q1: Multiple in jessie Q2: Requiring specific init is forbidden ii. Q1: Multiple in jessie Q2: Requiring default init is permitted iii. Q1: Single in jessie+1 Q2: Requiring default init is permitted Of these (ii) would cause the non-default inits to rot. Unless anyone thinks this is a useful option I don't think we should vote on it. ii is my preferred option. I think it's the option that makes the most sense. I don't agree that it will necessarily cause non-default inits to rot. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
