Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97086
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.223.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <BY2PR02MB298EF826D93C2D23090EB4AACB20@BY2PR02MB298.namprd02.prod.outlook.com>
References: <CAL=_i_m79Q3MuvvuhNcxiXF-ARJOW22eGJSoYMZBct6d_xxY3w@mail.gmail.com>
 <CAEZPtU6Y-AYyH1-rx9zOhTXxJC5XT8uh6gbyWJQWoyWo3WofOQ@mail.gmail.com>
 <CAL=_i_mZryk1ofAyMwpBGq=OvQngvCX-6ruCCFxL4HFq=OQ3=A@mail.gmail.com> <BY2PR02MB298EF826D93C2D23090EB4AACB20@BY2PR02MB298.namprd02.prod.outlook.com>
Date: Sun, 20 Nov 2016 13:30:38 +0000
Message-ID: <CAL=_i_kTywMU0DZV+giVWp4Go8sG1qGKBgrwWdYMLwt4eo5-rA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f6dd28ccdf40541bb8bc1
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
From: pthreads@pthreads.org (Joe Watkins)

--001a113f6dd28ccdf40541bb8bc1
Content-Type: text/plain; charset=UTF-8

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 <zeev@zend.com> wrote:

> > -----Original Message-----
> > From: Joe Watkins [mailto:pthreads@pthreads.org]
> > Sent: Saturday, November 19, 2016 6:11 AM
> > To: Pierre Joye <pierre.php@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
>
>

--001a113f6dd28ccdf40541bb8bc1--