Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91021
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain joeconstant.com from 209.85.220.51 cause and error)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <6F.D4.55829.C14FCA65@pb1.pair.com>
Date: Sat, 30 Jan 2016 11:07:07 -0700
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <FD83CB87-9CD4-49A9-8D84-6D5C05BE1E9D@joeconstant.com>
References: <6F.D4.55829.C14FCA65@pb1.pair.com>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] Should we rethink the 50%+1 requirement for non-"language changes"?
From: joe@joeconstant.com (Joe Constant)

As someone who has never participated with intervals before and only just re=
cently subscribed to the list, I would like to see a minimum percentage of v=
oting members participating in a vote for something to pass. In my interpret=
ation of the current rules, a measure could pass with only 3 votes cast (2 f=
or / 1 against). In fact, there was a recent proposal that passed with only 1=
1 votes cast. If that few of voting members are participating, maybe the pro=
posal wasn't clear enough (or maybe it's just not needed at all)?  Sure you c=
an argue that they had ample time to discuss, but I would say perhaps they j=
ust saw no value in it. If a proposal isn't offering enough value for the gr=
eater community, maybe it doesn't belong in core and should be either a pecl=
 extension or userland code?


Joe Constant



On 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 pro=
cess again. Under the Voting RFC[2], "Language changes" (in practice, change=
s 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 mo=
re permanent and shouldn't be arbitrary. However, there's no justification g=
iven for why other RFCs *shouldn't* receive the same level of scrutiny.

Consider that the language, in practice, is not simply the syntax and semant=
ics specified by the language specification and implemented by the Zend Engi=
ne 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 b=
e very useful for running real PHP applications, and it is only with conside=
rable difficulty that you could write PHP code without them. In fact, certai=
n key primitive operations on PHP's built-in datatypes are only exposed thro=
ugh functions in ext/standard! And yet, RFC votes on changes to the extensio=
ns are held to a lesser standard than changes to the syntax.

Another thing to consider is the types of changes that RFCs propose. These a=
re usually used for changes that should not simply get in through consensus a=
round a pull request. This can range from simply adding new functions, to ma=
king backwards-incompatible changes. These are not decisions to be taken lig=
htly.

Finally, I think that a proposal that is good enough will have no trouble ac=
hieving 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-"langua=
ge changes" to 2/3? At the very least, I think we should have this for backw=
ards-incompatible changes. If there's enough support, I'll write an RFC, tho=
ugh 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 procedu=
ral things like this.)

Thanks!

[1] https://wiki.php.net/rfc/openssl_aead
[2] https://wiki.php.net/rfc/voting
--=20
Andrea Faulds
https://ajf.me/

--=20
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php