Den 2016-01-30 kl. 18:34, skrev Andrea Faulds:
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
I'm thinking on RFC's that are:
- Not technically advanced
and/or
- Provides value in making life easier for programmer
and/or
- Belongs to ext with small audience
and/or
- Is a small feature
Would they benefit from this proposal or would it lead
to that certain categories of RFC's would never pass?
In the OPENSSL case it would have lead to a not pass.
Judging from the discussion it didn't seem like there
was resources to make a bigger thing, meaning that
this small addition would not be part of PHP in the
the short to medium-term perspective.
Regards //Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
