Re: Call for Votes (Re: glibc's getaddrinfo() sort order)
Ian Jackson writes ("Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> There is apparently no counterproposal, so I hereby propose and call
> for a vote on the following resolution:
The one-week voting period has now finished.
Result:
Further Discussion.
The choices were:
Choice X: Do not use rule 9, overrule maintainer, etc., as above.
Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
Choice F: Further discussion
The votes were (decreasing preference listing for each voter):
Ian: X F S
Andi: X F S
AJ: F XS
Steve: F X S
Determination of the winning outcome:
X vs. F: 2x X > F (Ian, Andi); 2x X < F (AJ, Steve).
X therefore fails since it needs 3:1.
S vs. F: Everyone agrees that S < F, so S fails.
Only F remains.
Discussion regarding supermajority mechanics:
Constitution A.6(3) says that failing to meet a supermajority
completely removes the option from consideration. Therefore if
anyone had voted X S F they would have left themselves open to their
vote being counted as in favour of S due to X's elimination for lack
of supermajority.
In the past we have sometimes used the phrasing "we overrule the
maintainer if we get the required supermajority". This has a subtly
different effect. In this case this would have resulted in us having
to ask the Chairman for a casting vote between X(non-overrule) and F.
Are we 100% clear who the Chairman is at the moment ?
There is of course a third alternative construction for the ballot:
put both options on as separate options. This would I think be the
cleanest approach in cases where significant confusion might arise;
and I think that with hindsight I ought to have done that in this
case. Providing two separate options means that I would have been
able to express my preference: X(overrule) F X(non-overrule) S.
People who propose resolutions for the TC should consider which of
these ways of doing it are best.
Ian.
Reply to: