Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6F.D4.55829.C14FCA65@pb1.pair.com>
References: <6F.D4.55829.C14FCA65@pb1.pair.com>
Date: Sat, 30 Jan 2016 23:04:40 +0100
Message-ID: <CAF+90c8ojjKqHqZcOZbanji3YokoQQHmZFjxKRWyz_znNMb-hQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141fa829c09e2052a94566d
Subject: Re: [PHP-DEV] Should we rethink the 50%+1 requirement for
 non-"language changes"?
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1141fa829c09e2052a94566d
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 30, 2016 at 6:34 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi everyone,
>
> The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
> process again. Under the Voting RFC[2], "Language changes" (in practice,
> changes to syntax and semantics) require at least a 2/3 majority to pass
> when they come to a vote, whereas changes that don't fall under that
> category require a mere plurality of more Yes votes than No votes, aka
> "50%+1".
>
> The stated justification for the 2/3 requirement is that such changes are
> more permanent and shouldn't be arbitrary. However, there's no
> justification given for why other RFCs *shouldn't* receive the same level
> of scrutiny.
>
> Consider that the language, in practice, is not simply the syntax and
> semantics specified by the language specification and implemented by the
> Zend Engine or HHVM. PHP's bundled extensions are also an important part of
> PHP which define the language: an implementation of PHP which lacked them
> would not be very useful for running real PHP applications, and it is only
> with considerable difficulty that you could write PHP code without them. In
> fact, certain key primitive operations on PHP's built-in datatypes are only
> exposed through functions in ext/standard! And yet, RFC votes on changes to
> the extensions are held to a lesser standard than changes to the syntax.
>
> Another thing to consider is the types of changes that RFCs propose. These
> are usually used for changes that should not simply get in through
> consensus around a pull request. This can range from simply adding new
> functions, to making backwards-incompatible changes. These are not
> decisions to be taken lightly.
>
> Finally, I think that a proposal that is good enough will have no trouble
> achieving a 2/3 majority anyway. In practice, many RFCs pass by unanimous
> vote!
>
> So, would there be support for raising the passing threshold for
> non-"language changes" to 2/3? At the very least, I think we should have
> this for backwards-incompatible changes. If there's enough support, I'll
> write an RFC, though I'll have to figure out how exactly to change the
> rules. (Can the voting RFC be amended by another RFC? The RFC process isn't
> a good fit for procedural things like this.)
>
> Thanks!
>

I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC
that passes with 51:50 votes is clearly not an RFC that a consensus exists
on. On the contrary, it indicates a very controversial change which
requires further deliberation.

In the end, this change will not have significant impact on how many RFCs
we accept. The last time I looked into this, the vast majority of RFCs that
passed at all, also passed with 2/3 majority. This will only filter out a
few controversial cases.

Furthermore requiring a consistent quota for all RFCs will avoid the
inevitable bickering that seems to spring up with many "major" RFCs, about
whether or not a 2/3 vote is required in a particular instance. For RFCs
that are significant, but not clear language changes (like the PHP 7 naming
RFC, or the phpng RFC, or the int size RFC), there's always a dozen or two
mails in the discussion devoted to this most important of questions.

Thanks,
Nikita

--001a1141fa829c09e2052a94566d--