Afternoon Zeev, It first seemed like a very simple question to abolish 50%+1 votes, it quickly become apparent that this is not viable in any sense.
Maybe I should have spotted that it wasn't sensible, maybe Pierre did and thought I was crazy, maybe Pierre thought I had spotted it but didn't care ... I was just late to realise that what I was suggesting doesn't make sense :) I did later reply that I intend to properly review mine and other's ideas, and will be back with suggestions. Thanks for your input. Cheers Joe On Sun, Nov 20, 2016 at 1:01 PM, Zeev Suraski <z...@zend.com> wrote: > > -----Original Message----- > > From: Joe Watkins [mailto:pthre...@pthreads.org] > > Sent: Saturday, November 19, 2016 6:11 AM > > To: Pierre Joye <pierre....@gmail.com> > > Cc: PHP internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes > > > > Morning Pierre, > > > > That's not what the rules say. > > > > There will be a one week discussion period. > > > > Cheers > > Joe, > > Changing the rules should at the very least be as long as the longest > discussion period and the highest majority defined in the Voting RFC, and > arguably, longer (which I think it should be here). It's really not > sensible otherwise - a group with a simple majority could change the voting > rules to require only a simple majority for everything, and pass whatever > RFC it wants with a simple majority. Changing the rules is bigger than any > single language-level decision, as it effects all future decisions going > forward. > > The original Voting RFC was rushed, and we're all still suffering from the > consequences many years later. There's really no need to do it again. > > Regarding the substance of the RFC, I think Andrea and perhaps others > touched on an issue - a 2/3 majority doesn't make sense for situations when > we need to pick an option, when none of the options has any inherent bias > towards them. > > When we deal with features, we did define a bias-for-status-quo, which > means a 2/3 majority is needed to change it. I agree that the definition > of 'features that change the language' is a poorly phrased one (file under > 'rushed'), and that other types of features should also be passed in a 2/3 > vote. > > However, there are decisions which really boil down to nothing more than > an opinion, where even if the status quo exists or is implied - there's no > inherent difference between the choices. For example, the decision on how > to version PHPNG that we faced about a year and a half ago. Should '7' > have required a 2/3 majority, because '6' is the perceived default? I > would disagree. It's a simple matter of opinion, doesn't change the > language in any way, and 6 isn't more 'status quo' than 7 in any way that 7 > is more than 6. Also, other administrative decisions, such as delaying a > release for whatever reasons (like we did for the inclusion of OPcache, > IIRC) - should also be a simple majority. > > I think the test that Michael brought up - "does it have any backwards > compatibility or forwards compatibility implications?", is probably the > right one to have. In other words - if it breaks BC, it requires a > supermajority. If it adds something that, if removed/changed in the > future, would introduce BC - it requires supermajority. Otherwise - it's a > simple majority (>50%, or even just the option that got the most votes in > case of a 3-way or 4-way vote). On top of that, to clarify, the rules > themselves should definitely require supermajority to change (arguably > higher than the current 2/3 we have; the original Voting RFC was passed in > consensus). > > Zeev > >
