Bug#727708: init system resolution - revised proposal
Don Armstrong wrote: On Thu, 30 Jan 2014, Josh Triplett wrote: Ian Jackson wrote: Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. For instance, consider a gnome-session-systemd package which uses systemd user sessions, provided in parallel with a compatibility package that does not. Or, consider the systemd-shim package. As written, this clause would prohibit such alternative packages, even though *collectively* the packages satisfy this requirement. Using software instead of packages sidesteps this problem, I think, since that avoids the technical details of how such compatibility is implemented. How confident are you that the entire technical committee and the community of people filing bugs in the future will share your interpretation of that statement in the resolution, versus the interpretation that would result in an automatic RC bug on *any* package that Depends: systemd-sysv (or logical equivalent), even if an alternative package exists? And to ask the reverse question: given your interpretation above, how averse are you to making some kind of clarification along the lines of what you said above official rather than unofficial? I'd hate to see people arguing over this ruling later if a one-sentence clarification could make it completely unambiguous. - Josh Triplett -- 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/20140131082735.GA30160@leaf
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 22:43 +0400, Sergey B Kirpichev a écrit : 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.” Is this all? Yes, this is all. Anyone who knows how Linux works doesn’t consider sysvinit a viable choice today. There is no need for lengthy argumentations, because there is nothing to argue against. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391157525.18551.921.camel@dsp0698014
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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140131100713.ga13...@darkstar.order.hcn-strela.ru
Bug#727708: TC resolution revised draft
On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, Hi Josselin, I'm not sure what you mean here, could you care to elaborate? Neil signature.asc Description: Digital signature
Bug#727708: init system resolution - revised proposal
Josh Triplett writes (Bug#727708: init system resolution - revised proposal): A couple of comments inline below. ... There is an issue with this wording, which I don't think is intended. Sometimes, the easiest way to maintain support for multiple init systems involves having a family of packages, each of which enables support for one init system or family of init systems. For instance, consider a gnome-session-systemd package which uses systemd user sessions, provided in parallel with a compatibility package that does not. Or, consider the systemd-shim package. As written, this clause would prohibit such alternative packages, even though *collectively* the packages satisfy this requirement. I would suggest adding language like the following, optionally with the following [non-binding] example: This is why we use the word software, not packages. Packages which form part of a set of alternatives integrating with different init systems need not individually run on other init systems, as long as the packages collectively meet the requirements of this section. [ For example, a package using systemd to launch a user session, provided as an alternative to a package that runs on sysvinit, need not itself run on sysvinit. ] I agree with the intent here but I think it's best done in policy rather than in the TC resolution. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21227.37234.22617.972...@chiark.greenend.org.uk
Bug#727708: init system resolution - revised proposal
Keith Packard writes (Re: Bug#727708: init system resolution - revised proposal): Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good ballot. Steve, Colin, Keith: let us know, and perhaps we can start the vote sooner. I can vote with this ballot. Thanks. Sorry I had to disappear in the middle of the meeting; that all turned out for naught as the flight I was on got canceled, and I'll be home for the weekend after all. Well, I guess you get a weekend at home as compensation for the hassle. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21227.37283.406219.421...@chiark.greenend.org.uk
Bug#727708: init system resolution - revised proposal
Josh Triplett writes (Bug#727708: init system resolution - revised proposal): How confident are you that the entire technical committee and the community of people filing bugs in the future will share your interpretation of that statement in the resolution, I'm confident that the policy maintainers will flesh out the meaning appropriately. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21227.37382.434487.649...@chiark.greenend.org.uk
Bug#727708: init system resolution - revised proposal
To CTTE, In the wait for your decision next week, many of us assume that you take into consideration the many misleading and false statements that have been written about about sysvinit + openrc/insserv. Additionally, consider this, please: Adopting systemd (and gnome, dbus-kdbus, wayland, etc depending on it) is very dangerous for the future of Free Software :-( (I wonder which view FSF would have if they had been involved) Thanks, have a nice weekend! -- 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/1391175670.20080.53.ca...@g3620.my.own.domain
Bug#727708: TC resolution revised draft
Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit : On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, Hi Josselin, I'm not sure what you mean here, could you care to elaborate? Here is my understanding of the issue, on a simplified example. Let's restrict to the following 4 options from the last draft ballot: DT systemd default in jessie, requiring specific init is allowed DL systemd default in jessie, requiring specific init NOT allowed UT upstart default in jessie, requiring specific init is allowed UL upstart default in jessie, requiring specific init NOT allowed And let's suppose that the CTTE has 4 members: P1 (the chairman), P2, P3 and P4. Let's suppose that the vote is as follows: P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT P1 and P2 both prefer systemd over upstart, while P3 and P4 prefer upstart over systemd. But P1 and P2 disagree on the coupling question (T versus L), while P3 and P4 agree with each other. The Condorcet winner of this vote is UT (and note that the casting vote of P1 is not needed here, since UT is alone in the Schwartz set). This result is not necessarily what one would have expected beforehand. In particular, if the ballot had not included the options about coupling, then systemd would have won because of the casting vote of the chairman. Fundamentally, the reason of the victory of upstart in this hypothetical vote is that systemd proponents prefer to lose on the coupling question rather than on the init system question, while the upstart proponents have the opposite preference over the relative importance of these two questions. Of course, in the alternative scenario with two consecutive ballots (one on the init, followed by one on the coupling), it would not have been possible to express this preference over the relative importance of the two questions, so one could argue that this is a feature of the single ballot with all options. Still, my example shows that putting the two questions on the same ballot is not just about letting people express different coupling choices for different init systems. It can have the more fundamental effect of changing the winning init system. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#727708: TC resolution revised draft
Hi Neil, Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit : On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, I'm not sure what you mean here, could you care to elaborate? Wikipedia has a nice description of how tactical voting works: http://en.wikipedia.org/wiki/Tactical_voting#Types_of_tactical_voting In the current example, a voter can rank insincerely her init system choices after #1, in order to give less chances to the one she would have ranked #2 sincerely. With only two realistic options (systemd / upstart), this problem doesn’t exist. But introducing more options on the ballot, it becomes possible to obtain a rigged outcome. The vote being public, it is all the more easier to see how you should rank other options than your preference in order to defeat them all. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391177210.18551.977.camel@dsp0698014
Bug#727708: TC resolution revised draft
On 31/01/14 14:02, Sébastien Villemot wrote: P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT Of course, in the alternative scenario with two consecutive ballots (one on the init, followed by one on the coupling), it would not have been possible to express this preference over the relative importance of the two questions, so one could argue that this is a feature of the single ballot with all options. Yes I think this is by design, and IMHO desirable. Imagine if the questions were uncoupled and decided in *reverse* order, someone might decide to compromise on their choice of init system, due to the result of the first decision making their original choice less palatable. I think that's what people are expressing in their vote. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: TC resolution revised draft
On 31/01/14 14:02, Sébastien Villemot wrote: the reason of the victory of upstart in this hypothetical vote is that systemd proponents prefer to lose on the coupling question rather than on the init system question If having systemd is still a preference despite the outcome of the other question, you can avoid losing on it by simply putting the systemd options with equal preference: DT = DL UL UT Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: TC resolution revised draft
On Fri, Jan 31, 2014 at 03:02:21PM +0100, Sébastien Villemot wrote: Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit : On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, Hi Josselin, I'm not sure what you mean here, could you care to elaborate? Here is my understanding of the issue, on a simplified example. Let's restrict to the following 4 options from the last draft ballot: DT systemd default in jessie, requiring specific init is allowed DL systemd default in jessie, requiring specific init NOT allowed UT upstart default in jessie, requiring specific init is allowed UL upstart default in jessie, requiring specific init NOT allowed And let's suppose that the CTTE has 4 members: P1 (the chairman), P2, P3 and P4. Let's suppose that the vote is as follows: P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT P1 and P2 both prefer systemd over upstart, while P3 and P4 prefer upstart over systemd. But P1 and P2 disagree on the coupling question (T versus L), while P3 and P4 agree with each other. The Condorcet winner of this vote is UT (and note that the casting vote of P1 is not needed here, since UT is alone in the Schwartz set). This result is not necessarily what one would have expected beforehand. In particular, if the ballot had not included the options about coupling, then systemd would have won because of the casting vote of the chairman. Fundamentally, the reason of the victory of upstart in this hypothetical vote is that systemd proponents prefer to lose on the coupling question rather than on the init system question, while the upstart proponents have the opposite preference over the relative importance of these two questions. Of course, in the alternative scenario with two consecutive ballots (one on the init, followed by one on the coupling), it would not have been possible to express this preference over the relative importance of the two questions, so one could argue that this is a feature of the single ballot with all options. ... I would argue your example shows the voters not understanding how the voting system works... Quoting the Debian Constitution: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. If in your example P1 and P2 would both rank FD (the default option further discussion) second, then DL wins. And if additionally P3 and P4 would rank FD second or third, then FD wins. The casting vote of the chairman sounds more powerful than it is in actually, since in any situation between two options where no option has a majority of at least the quorum, each side can prevent the other side from winning. So if for example 4 members of the TC would say only systemd is an acceptable choice, and the other 4 members of the TC would say only upstart is an acceptable choice, then any result other than further discussion would be caused by a voting error. And this is not a problem of the Condorcet voting system, this is due to the explicit statement There is a quorum of two. in the Constitution. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140131160635.ga30...@bunk.dyndns.info
Bug#727708: TC resolution revised draft
Josselin Mouette j...@debian.org writes: == optional rider M (Multiple init systems) == Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Where feasible, software should interoperate with non-default init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. Since this text just recommends common sense and is not even mandatory, I wonder what it is trying to achieve. We discussed this in our IRC meeting yesterday, largely because I asked the same question. The consensus was that common sense isn't really that common, and including such text might help reduce the number of questions that come up and have to be answered later. Bdale pgp9uz5__S4An.pgp Description: PGP signature
Bug#727708: TC resolution revised draft
On Fri, 31 Jan 2014, Josselin Mouette wrote: With only two realistic options (systemd / upstart), this problem doesn’t exist. But introducing more options on the ballot, it becomes possible to obtain a rigged outcome. The vote being public, it is all the more easier to see how you should rank other options than your preference in order to defeat them all. If this actually becomes the case, we can vote again, or change our votes. Burying will be pretty obvious in this case, after all. -- Don Armstrong http://www.donarmstrong.com One day I put instant coffee in my microwave oven and almost went back in time. -- Steven Wright -- 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/20140131185817.gl5...@teltox.donarmstrong.com
Bug#727708: TC resolution revised draft
On Fri, 31 Jan 2014, Don Armstrong wrote: If this actually becomes the case, we can vote again, or change our votes. Burying will be pretty obvious in this case, after all. Scratch what I said. Given that there isn't actually a potential compromise winner in this case, or anyone who has expressed a preference to rank the a compromise winner over any of the two front-running options, I can't personally come up with a case where burying could actually happen. If you believe that I'm mistaken, please provide an actual example relevant to this particular ballot (and stated preferences) where this could actually occur. -- Don Armstrong http://www.donarmstrong.com Identical parts aren't. -- Beach's Law -- 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/20140131202815.gn5...@teltox.donarmstrong.com
