[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#727708: Call for votes on init system resolution

Bug cc dropped, replaced with -ctte.

On Fri, Feb 07, 2014 at 08:29:27AM +0200, Adrian Bunk wrote:
> On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> > It's really pretty terrible to actively use FD to try to block options
> > that aren't your favourite.
> When you are saying "a set of proposals considered reasonable by all the 
> members", that basically implies "don't offer the T rider options" since 
> these are options that are not considered reasonable by at large part 
> (at least 3 members) of the TC.

I'd consider that tactical voting. Basically, I think the value in the
FD option is to be able to say "this option has not been fully baked,
and more discussion would be helpful to ensure it is properly understood
and the consequences are clear".

That's a long way different to saying "if my preferred option does not
win, we should delay making a decision and keep holding votes until it
does win".

It's obviously not possible to tell which one of those motivations is
behind a vote just from looking at the vote; but if you're voting FD above
an option and not trying to make it clearer what the consequences are,
or trying to improve it to make it better understood or better match
people's intentionds, I think it's fair to say you're abusing the FD
option. Proposing options, then voting them below FD seems especially
hard to rationalise as anything but an attempt to use the voting system
to prevent a decision being made.

That the Debian voting system uses the FD to enforce quorum and
supermajority requirements makes it effective to vote tactically. I
think that's a mistake though (and given my involvement, probably my
istake at that).

> What we see in the combined vote is actually that DL is an option
> that makes both sides win in what they consider their most important
> question - and that seems considered reasonable by all TC members.

With only 6 of 8 votes in, I don't think you can draw that
conclusion. Half of the tech ctte members who indicated a preference for
systemd didn't put in a ballot for that vote; and the vote was cancelled
due to all four of the ctte members who'd indicated a preference for
upstart wanting to give Steve a chance to come up with an alternative
to L/T.

Given neither quorum not supermajority requirements are an issue in
this vote; here's how a pure Condorcet treatment of the votes would look
(ignoring GR, and the OpenRC, SysV options):

  ian, steve, andi:
         UL DL FD UT DT
  colin: UL DL UT DT FD
  russ:  DT DL UT FD UL
  don:   DT DL UT UL FD
  bdale, keith: 
         DT > DL UT > UL
         DT > UT DL > UL
         DT > UL,FD

  DL > UT (6:0)
  DT = DL (4:4)
  DT = UL (4:4)
  DT = UT (4:4)
  UT = UL (4:4)
  DL = UL (4:4)

  UL > FD (5:1)
  DT > FD (5:3)
  DL > FD (6:0)
  UT _ FD (3:3)

The transitive defeats are then:
  DL > UT
  UL, DT, DL > FD
and possibly (depending on the details of Keith and Bdale's ballots):
  UT > FD
  FD > UT

Since there aren't any circular transitive defeats, Schwartz set is
every unbeaten option, and thus is:

  DL, UL, DT

independent of Keith and Bdale's ballots. There aren't any defeats
between these options, so it's down to a casting vote.

In the hypothetical where the votes were:


the only defeats would be:

  8:0  DL > FD > UT

and the Schwartz set would be {UL, DT, DL} with the casting vote
choosing amongst that set (ie, exactly the same outcome).

If half the committee thinks DT needs more discussions, and the other
half thinks UL needs more discussion, I would hope that they'd actually
undertake that discussion, and propose a ballot with UL', DT', and DL
as options, rather than just choosing one straight away.

On the other hand, if the committee has sincerely finished discussion and
wants to come to a conclusion, I think that's the right outcome for such
a precisely divided issue, and that the fact the Debian voting system
would actually drop UL and DT in the above case is a problem. I think
that's due to "insincere" ranking of FD, but if it is, then rewarding
that is a bug in the voting system.

Having Further Discussion be a "yes" or "no" option, rather than being
ranked against other options would probably have been a better plan --
the result then would presumably be 8:0 FD>*, or 8:0 *>FD. I don't know
how you'd reasonably require a supermajority for some options but not
others in that case though.


Reply to: