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/ slanga...@ubuntu.com vor...@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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
