Discussion:
Bug#727708: TC resolution revised draft
(too old to reply)
Philipp Kern
2014-01-30 15:46:18 UTC
Permalink
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?

Kind regards
Philipp Kern
Philipp Kern
2014-01-30 15:49:16 UTC
Permalink
== 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?

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…

Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-ctte-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@hub.kern.lc
Ian Jackson
2014-01-30 15:57:36 UTC
Permalink
Post by Philipp Kern
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.
Post by Philipp Kern
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.
Ian Jackson
2014-01-30 17:22:21 UTC
Permalink
Post by Philipp Kern
== 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.
Ian Jackson
2014-01-30 15:50:44 UTC
Permalink
Post by Philipp Kern
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.)
Josselin Mouette
2014-01-31 08:33:33 UTC
Permalink
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-ctte-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@dsp0698014
Neil McGovern
2014-01-31 11:55:40 UTC
Permalink
Post by Josselin Mouette
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
Sébastien Villemot
2014-01-31 14:02:21 UTC
Permalink
Post by Neil McGovern
Post by Josselin Mouette
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
Josselin Mouette
2014-01-31 14:06:50 UTC
Permalink
Hi Neil,
Post by Neil McGovern
Post by Josselin Mouette
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@dsp0698014
Steven Chamberlain
2014-01-31 14:13:59 UTC
Permalink
Post by Sébastien Villemot
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
***@pyro.eu.org
Steven Chamberlain
2014-01-31 14:30:11 UTC
Permalink
Post by Sébastien Villemot
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
***@pyro.eu.org
Adrian Bunk
2014-01-31 16:06:35 UTC
Permalink
Post by Sébastien Villemot
Post by Neil McGovern
Post by Josselin Mouette
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.
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
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@bunk.dyndns.info
Bdale Garbee
2014-01-31 17:41:00 UTC
Permalink
Post by Josselin Mouette
== 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
Don Armstrong
2014-01-31 18:58:17 UTC
Permalink
Post by Josselin Mouette
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@teltox.donarmstrong.com
Don Armstrong
2014-01-31 20:28:15 UTC
Permalink
Post by Don Armstrong
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
Ian Jackson
2014-02-01 17:10:55 UTC
Permalink
Post by Sébastien Villemot
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.
Uoti Urpala
2014-02-01 18:05:09 UTC
Permalink
Post by Ian Jackson
Post by Sébastien Villemot
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-ctte-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@glyph.nonexistent.invalid
Anthony Towns
2014-02-01 22:06:33 UTC
Permalink
Post by Uoti Urpala
Post by Sébastien Villemot
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
Adrian Bunk
2014-02-06 06:13:02 UTC
Permalink
Post by Adrian Bunk
...
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
Loading...