Hello, On Tue, 30 Apr 2019 at 20:25, Zeev Suraski <z...@php.net> wrote: > > On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans <der...@php.net> wrote: > > > On Mon, 29 Apr 2019, Zeev Suraski wrote: > > > > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. <george.bany...@gmail.com> > > wrote: > > > > > > > I think this just boils down to what is an acceptable majority, if > > > > 2/3 is not enough then 3/4 but this is another debate altogether. > > > > > > > > > > I've argued in the past that it would make sense to require a 9/10 > > majority > > > for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. > > > Usually (in the vast majority of cases), it either clears a nearly > > > unanimous vote - or it doesn't even come close to 2/3. > > > > > > RFCs that have a high number of votes (i.e., that people feel strongly > > > about), and barely pass the 2/3 mark - are controversial and saw > > division. > > > Yes, it means that out of the (almost random) group of people who are > > > currently enabled to vote by our (flawed) voting system > > > > If you think it's flawed > > > It's not that I think it's flawed - I know it's flawed. It doesn't > implement what was agreed upon when the Voting RFC was enacted. > > > > , you know that the RFC process is there for > > anybody to change it. Joe already managed twice towards what you > > suggested in your stalled RFC: > > > > - https://wiki.php.net/rfc/abolish-short-votes > > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted > > against this one to raise the barrier from 50%+1 to ⅔rds). > > > > I'm well aware of it. In doing that, I think we greatly complicated the > prospects of fixing the voting eligibility - which is an infinitely hotter > potato to handle. Both 'abolish' RFCs enjoyed popular support and had very > little touchy subjects - unlike the topic of who gets to vote, or the > prospect of moving to a consensus-based system. > > > It's absolutely fine to dislike short tags. It's absolutely fine to > > > believe it shouldn't have been introduced. But the gap between that, > > > and thinking it's fine to remove it - is very, very big. > > > > But the fact is that the RFC passed. And retroactively changing rules > > because somebody don't agree with a decision is making a farce out of > > the process. > > > > I've detailed the issues with the RFC in my other reply. > > I'm well aware that I'm spending quite a bit of 'credit capital' by > weighing in on this, and I'm enjoying it roughly as one would enjoy having > their tooth pulled out without anesthesia (which still pales in comparison > to what it would take to fix our voting process, which will probably be > akin to having an entire set of teeth pull out in the same way). The > reason I'm still doing it is that it's clear this RFC was flawed in its > voting options, its substance, and the level of discussion that surrounded > it (the last one is my opinion, the first two are facts) - and it will have > HUGE implications on hundreds of thousands if not millions of users. So as > I said when I first engaged this thread - as much as I'm 'enjoying' this, I > prefer to take the personal hit and do whatever I can to prevent our users > from taking the hit. > > If we are to inflict this hit on our users - we need to have each and every > t crossed and i dotted. > > Zeev
Some languages out there have an idiom for this kind of a situation: This thread right here is making an elephant out of the fly. Meaning something is exaggerating or make something more serious than it actually is. Worth noting another inconsistency here that we've missed. PHP 7.4 has introduced many BC breaks actually already. Without this level of problems: - *nix build system now uses pkg-config and basically has changed so many configure options that building this is a completely new chapter on its own - removed wddx - removed interbase - entire Backward Incompatible Changes section in the UPGRADING file: https://github.com/php/php-src/blob/PHP-7.4/UPGRADING The deprecation in PHP 7.4 (or even if there wouldn't be any deprecation here at all) and removal of some short tags in PHP 8 is the least of users problems I think. If the next RFC on this topic would happen (in my opinion it is pointless) it should make only something more clear. That is how to remove them. In PHP 8.0 directly as is now the result of this RFC or in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything in between is a more or less a revert of the original RFC which would then come to a question of why making these RFCs at all and why voting even matters. Without these kind of "hacks" PHP wouldn't even move forward anymore. Contributing to it would be in most cases only maintenance, fixing bugs and compatibility with platforms out there. So nothing exciting anymore like making it more syntactically correct, more logical etc. (these are very important changes also beside new functionality and extensions). -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php