Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91022
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <6F.D4.55829.C14FCA65@pb1.pair.com>
References: <6F.D4.55829.C14FCA65@pb1.pair.com>
Date: Sat, 30 Jan 2016 11:24:39 -0700
Message-ID: <CAFMT4Nrit6xQzaUFdDfhMqA2zc9gW83wA-pyh3hrAxzMtYo9MA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Should we rethink the 50%+1 requirement for
 non-"language changes"?
From: levim@php.net (Levi Morrison)

On Sat, Jan 30, 2016 at 10:34 AM, 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!
>
> [1] https://wiki.php.net/rfc/openssl_aead
> [2] https://wiki.php.net/rfc/voting
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

I've been wanting to propose bumping the required % to always be 2/3
for quite some time and just didn't have the energy or time to conduct
a discussion about it. I fully support this idea. We are at a stage in
PHP's lifecycle where I think we should be more united on changes and
additions or they shouldn't make it it.