> -----Original Message----- > From: Christoph M. Becker [mailto:cmbecke...@gmx.de] > Sent: Thursday, September 14, 2017 12:25 AM > To: Sara Golemon <poll...@php.net>; PHP internals <internals@lists.php.net> > Subject: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting > RFC votingthreshold to 60% > > On 13.09.2017 at 22:42, Sara Golemon wrote: > > > https://wiki.php.net/rfc/rfc.voting-threshold > > > > This topic has come up on the mailing list a few times, so I'd like to > > formally open the topic for discussion. > > > > I'm generally pretty liberal when it comes to allowing the PHP > > language to evolve and explore its identity, but the truth is a > > feature that has 30 people vote against it and 31 people vote in favor > > of it is not a mandate by any stretch of the imagination. It's an > > opportunity to examine why a divide exists and if we're all being > > honest with each other, improve the original idea before it becomes a > > maintenance burden. > > Thanks for taking the initiative on this! > > FTR: Zeev has also started preparing an RFC which includes this voting > threshold, besides further issues: <https://wiki.php.net/rfc/voting2017>.
Oh wow, I was hoping to bake it for a while longer before public scrutiny :) Still a lot of work to go on it. Realistically I'm only going to bring it up for discussion sometime around late October because I'm actually going to be off the grid for most of the 2nd half of September and most of October. > IMHO, a 2/3 majority would be most suitable for any changes to php-src. > Most votes have even been clearer, and I believe most (if not all) which would > have failed a 2/3 threshold would have failed 60% as well. (Zeev presented > more detailed stats on this list a while ago.) Having a 2/3 threshold for > all php- > src change related votes would at least avoid the discussion into which > category > the vote falls, though. I agree, and the only exception that may make sense is the addition of functionality under an extension's namespace/pseudo namespace. E.g., I'm not sure we need a 2/3 vote for a new oci8_*() function, or a new method added to ext/mysqli. There are no downwards compatibility considerations, and it seems reasonable enough that the subject matter experts (the extension maintainers) will be given jurisdiction here. To be honest, I'm not sure we need a vote at all for those, 2/3 or otherwise. But this is pretty much the only example I can think of. That said, I do think that if we finally have the mental strength and stamina to tackle the laconic 2011 Voting RFC, we should tackle it more thoroughly and try to solve as many of the issues that came up over the years. This is what I'm attempting to do in the RFC I started drafting a couple of days ago - and that I'm NOT YET PUBLICLY DISCUSSING :) Zeev
