Bug#727708: TC resolution revised draft
On Fri, Jan 31, 2014 at 06:06:35PM +0200, Adrian Bunk wrote: ... 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. For the record: The last paragraph I wrote here is nonsense (and unfortunately noone noticed and corrected my mistake). The reason why FD would win in this scenario is not the quorum, the reason is that every option that should be taken into consideration has to beat FD. 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: TC resolution revised draft
Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT This is a nice example which actually demonstrates why these questions need to be voted on in a single ballot. If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote on T-vs-L until they know how the vote on U-vs-D will turn out. And of course the order would have to be fixed, and not depend on assumptions about the preferences of the voters; so it's not an answer to say then we'll do U-vs-D first. 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: TC resolution revised draft
On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote: Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT This is a nice example which actually demonstrates why these questions need to be voted on in a single ballot. If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote on T-vs-L until they know how the vote on U-vs-D will turn out. I believe that part was just a typo in the message you're replying to, and it should be UT UL DT DL for P3 and P4. He wouldn't have written about relative importance of these two questions if he had intended the answer to one question to change depending on the answer to the other. So his example was one where the D/U and L/T choices were independent for every voter, but combining them into a single ballot produced a result different from the expected result of voting on each independent question separately. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
On 2 February 2014 04:05, Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
Sébastien Villemot writes (Bug#727708: TC resolution revised draft):
P1: DT UT DL UL
So his example was one where the D/U and L/T choices were independent
for every voter,
Formally, there isn't a way to vote for an arbitrary partial order by
ranking options. ie, you can't vote for:
DT UT
DL UL
UT UL
DT DL
without inadvertently and insincerely expressing further preferences.
Err, yes you can:
DT UT = DL UL
works fine. In which case the votes would be:
P1: DT UT = DL UL
P2: DL UL = DT UT
P3: UT DT = UL DL
P4: UT DT = UL DL
and the pairwise defeats are:
DT DL : 3 vs 1
UT UL : 3 vs 1
DT UL : 1 vs 0
UT DL : 2 vs 1
UT = DT : 2 vs 2
UL = DL : 2 vs 2
Transitive defeats are then just:
DT t. defeats DL, UL
UT t. defeats DL, UL
Schwartz set: { DT, UT }
There aren't any defeats in the schwartz set, so P1 uses a casting
vote to choose which of DT, UT is the winner, presumably DT.
Compare that to the corrected example's potential results:
combined: UT wins
D/U first: draw, tie break = D, T wins, so DT
L/T first: T wins, draw, tie break = D, so DT
So I think you can put the difference down to either people expressing
insincere preferences, or that the additional, sincerely held,
preferences expressable via the combined vote having an effect on the
outcome, which shouldn't be surprising.
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: TC resolution revised draft
Le jeudi 30 janvier 2014 à 14:40 +, Ian Jackson a écrit : D DM U UM O OM V VM GR and of course FD [snip text for 10 different options] == 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. Given the Condorcet voting method is susceptible to tactical voting, especially when the votes are public, I fear it would make it very tempting for some members to manipulate the vote using this added complexity. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 pgp3JP0qCbtdL.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
I have taken Bdale's text, reformatted it a bit, and added the GR rider and the multiple init systems rider texts. For the GR rider I used the version from my previous standalone proposal. I see Bdale has a different text in git. I'll discuss that in a moment. For the multiple init systems rider I used my original text for the first sentence and Don's formulation for the second sentence. I have also added an explicit option for declining to decide and asking the project to do it via GR. I think such an option would be much better than FD. Below is the result. This in principle results in 9 real options plus FD. I'm going to call the options by the subsets of the text they use: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. I think O and V are probably sufficient for those options, as the desire to support multiple systems there is probably obvious so doesn't need saying. That would leave us with 7 real options which isn't too unmanageable. The text below is in the tc git repo. I'm going to follow up in a moment with a formal action to propose a resolution, starting the constitutional discussion period. Ian. == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == 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. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Ian Jackson writes (TC resolution revised draft): For the GR rider I used the version from my previous standalone proposal. I see Bdale has a different text in git. I'll discuss that in a moment. I see that Bdale has his own draft in git. The differences are: * My GR rider is different to Bdale's. Mine is more comprehensive; it specifically allows the GR to override any other part of the resolution, and that any contrary GR completely replaces the TC resolution. I think this is better. This is particularly true given that the TC resolution might include the multiple init systems wording, which ought to be overrideable too. So for that reason I have kept my version rather than Bdale's. * My options have mnemonic letters. This is going to be relevant because some of them want to have the multiple init systems version. * Formatting is a bit different. Thanks, 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: TC resolution revised draft
On 30/01/14 14:40, Ian Jackson wrote: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. Couldn't it bias the outcome if votes might otherwise have been split between O and OM for example? And so better to leave them in? 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: TC resolution revised draft
Ian Jackson writes (TC resolution revised draft): I'm going to follow up in a moment with a formal action to propose a resolution, starting the constitutional discussion period. I hereby formally propose what I have called UM (text below). I also hereby formally propose DM as an amendment, but do not accept it. After I hear from other TC members on the merits of O vs OM and V vs VM, I will propose but not accept one of each, unless someone else gets there first. I suggest that those TC members who prefer to leave out the comments about supporting multiple init systems propose D and/or U. That will leave us voting on (most likely): Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Usystemd default in jessie, say nothing about multiple inits UM systemd default in jessie, support multiple inits Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion We should see what people say by email and at the meeting, but unless people disagree I think it would be sensible to have a formal discussion period of about a week. That would have us starting the vote on the 6th of February. Is everyone available to vote then ? Thanks, Ian. == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == 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. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Steven Chamberlain writes (Bug#727708: TC resolution revised draft): On 30/01/14 14:40, Ian Jackson wrote: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. Couldn't it bias the outcome if votes might otherwise have been split between O and OM for example? And so better to leave them in? Thanks for asking, but I think not. [1] Our voting system (Condorcet with Schwartz Cloneproof Sequential Dropping) is designed to cope with that. In actual practice I'm expecting to have a single Condorcet winner in which case splitting/joining options is totally irrelevant. Ian. [1] I'm starting to feel the need to thank anyone who makes a short and non-useless contribution, even if they happen to be wrong, since there are so many unhelpful emails now and such a bad atmosphere. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): On 2014-01-30 15:59, Ian Jackson wrote: Our voting system (Condorcet with Schwartz Cloneproof Sequential Dropping) is designed to cope with that. In actual practice I'm expecting to have a single Condorcet winner in which case splitting/joining options is totally irrelevant. I really hope you are right that it cannot be rigged. That said: How does Bdale's casting vote work with Condorcet? If there's a tie, both are in the set of winners and he'll break the tie using the order within his vote? Yes. See Constitution A.6. Thanks, Ian. (PS: I have replied to the bug. Please send messages on this subject to the bug, not just to the ctte list.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): So if we assume that upstart wins, would it be acceptable to depend on systemd (or vice versa)? We might then get a set called, say, Unity, depending on upstart and one called, say, GNOME, depending on systemd, which would not be co-installable. Maybe there should be a paragraph addressing this? I have tried to persaude my colleagues that it is necessary to exclude this possibility, but I don't seem to have succeeded. I do like the current phrasing wrt support of the non-default init system. But I don't see the question above addressed in it… You're right, it's not. Some of my proposed stronger wordings for the Multiple section do address it. However, with Russ, Bdale and Keith all saying they're opposed to having this paragraph at all, I would need the support of all the rest of the TC to include it. Hence my proposal for a compromise which Don has said he prefers to FD. (And even that may not be enough.) If you think it's important to explicitly vote on this question then I am open to putting it on the ballot. (Although the number of options starts to become rather unwieldy, in practice I expect the TC members not to have trouble ranking them.) I also don't know whether Bdale intends to use his casting vote to force a decision (and if so how far that decision will go), or whether he'll use it to acknowledge that the TC is split and punt the question to a GR. But I would guess the former. 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: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): On 2014-01-30 15:47, Ian Jackson wrote: == 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. So if we assume that upstart wins, would it be acceptable to depend on systemd (or vice versa)? We might then get a set called, say, Unity, depending on upstart and one called, say, GNOME, depending on systemd, which would not be co-installable. Maybe there should be a paragraph addressing this? So, my previous version of this rider was this: Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. (Same as above.) Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Different to above. Perhaps adding this: Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. would soften this text. I will ensure that something like this gets onto the ballot iff I hear from the project that they think it's important to vote on it in the TC (even if the TC seems likely to reject it). I'm obviously open to suggested wording improvements for the version M you see above (which is in the git repo) and this stronger compatibility requirement version. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
