On Sat, Jan 30, 2016 at 10:34 AM, Andrea Faulds <a...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
