Supermajority requirements and historical context [Was, Re: First call for votes for the Lenny release GR]
On Sat, Dec 20, 2008 at 12:48:43PM +0200, Antti-Juhani Kaijanaho wrote:
> On Fri, Dec 19, 2008 at 04:36:59PM -0800, Steve Langasek wrote:
> > if a majority of voters vote that we should put
> > Nvidia drivers in main, then your fundamental problem is that you have a
> > majority of people (or at least, voters) in Debian who think it's ok to put
> > Nvidia drivers in main. Your only real choices, then, are to persuade them
> > that they're wrong, live with it, drive them off, or leave.
> > The other option you're proposing here, to prevent them from doing what they
> > want to unless they have a 3:1 majority, reduces to "coerce the majority to
> > do what you say they should do, even though they don't think you're right".
> > Do you really think that's a solution to the above pathological scenario?
> In my eyes, this argument applies to any situation where a supermajority
> might be formally required, and in my opinion the corollary is that
> supermajorities are a bad idea in general.
> Do you agree with that corollary? If not, why not?
Yes, I agree that supermajority requirements are a bad idea in general.
- They have unpleasant side-effects when coupled with Clone-proof SSD, by
making certain types of strategic voting much more interesting to voters
(i.e., strategizing about contributing to the quorum requirements for a
particular option by voting it above or below FD when there's a mixture of
supermajority requirements on a single ballot - precisely what I've seen
discussed on Planet and IRC during the current voting round).
http://lists.debian.org/debian-vote/2002/11/msg00343.html
http://lists.debian.org/debian-vote/2002/11/msg00316.html
- Their nominal purpose is to prevent a tyranny of the majority, but in
practice they only place limits on the /size/ of the tyrannic majority; a
commitment to consensus-driven decision making, plus the right of any DD
to propose any compromise amendment they want to, are a much better
approach to preventing tyranny of the majority, and where these methods
are ineffective supermajority requirements won't help either, so
supermajority requirements are entirely superfluous from that POV.
http://lists.debian.org/debian-vote/2002/11/msg00241.html
The only argument in favor of a supermajority requirement for foundation
docs that I found compelling at the time this was brought up for discussion
was the concept of "institutional stability": if a particular change to the
DFSG doesn't enjoy *strong* support from a majority, there's a significant
risk of flip-flopping our Foundation Documents in a fairly short period of
time, as opinions in the project shift, and it's better to let the
Foundation Documents lag slightly behind opinion than to have a high degree
of churn in our highest-profile statements of principle.
http://lists.debian.org/debian-vote/2002/11/msg00357.html
http://lists.debian.org/debian-vote/2002/11/msg00264.html
http://lists.debian.org/debian-vote/2002/11/msg00253.html
http://lists.debian.org/debian-vote/2002/11/msg00266.html
This argument does IMHO not apply to making decisions about what Debian is
going to do. We shouldn't take decisions to set aside the DFSG lightly, but
the *process* for arriving at a decision should be lightweight. By that
standard, the past two months have been a failure on multiple levels.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
P.S. A quote that I found amusing when going through old mail:
"I don't agree with your assumption that we're not clever enough to think
of a way of introducing supermajority requirements without sacrificing
an important property of CpSSD."
http://lists.debian.org/debian-vote/2002/11/msg00311.html
Reply to: