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

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).


- 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.


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.


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."


Reply to: