On Sun, Apr 28, 2019 at 11:32 PM G. P. B. <george.bany...@gmail.com> wrote:
> On Sun, 28 Apr 2019 at 14:36, Zeev Suraski <z...@php.net> wrote: > >> As I said numerous times in the past, I'm a firm believer that >>>> controversial RFCs (ones that generate a lot of votes with a substantial >>>> number of opposers) should not pass. I think this is important when >>>> adding >>>> features - but it's actually a lot more important with deprecations. >>>> When >>>> there's substantial doubt whether a deprecation should go through or >>>> not, >>>> there should be no doubt at all - it shouldn't. This is one of the >>>> clearest cases if not the clearest one we've had to date. >>>> >>> >>> This IMHO applies to the deprecation vote which includes the default >>> change >>> >> >> From my POV it applies to all deprecations, although obviously taking out >> something that's been a basic building block for the last 20+ years is >> probably more of an issue than some 3rd party utility function. >> > > 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 - there are 2x more people that want the RFC to pass vs. not, but at the same time, it also means that there's a great number of folks who think that it's a Really Bad Idea. This is even stronger with deprecations, where the biggest downside is compatibility breakage. Unlike new features, where you simply have to illustrate that the feature is a good idea - here, you don't only have to demonstrate that the feature you propose to deprecate is a bad idea - but rather, that it's so bad - that we're better off removing it and inducing compatibility breakage on our huge, several million strong userbase. If a very substantial number of folks thinks otherwise, it should make others pause - even if they dislike this feature and think it's bad, and consider whether it's really so horrid that it must be removed. Unfortunately, this line of thought doesn't appear to be happening - and it seems that many vote in favor of deprecation based on whether or not they like the feature. 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. This was indeed the intention of the voting structure as I wanted to have a > vote to get see > if people were filling to remove it with PHP 8 or leave it longer in the > Engine. > > However looking at how some people voted against the deprecation notice > but for the removal > the only meaningfull conclusion I can come up with is that the change of > the default value is > the issue. > It's very difficult to deduce what people were thinking because the questions were not properly structured. Some people probably only voted on one vote and not the other, thinking the other is irrelevant. It's fairly difficult to guess how it influenced the final tally, all the more reason to properly restructure the vote and restart it. > >> I mean I don't see how we are in unchartered territory, the vote passed, >>> sure >>> with not a huge supra majority but it still passed. >>> >> >> We're in unchartered territory not from a process perspective, but in >> terms of the number of core devs who think it's a really bad idea and the >> fact we're rediculously close to the minimum threshold - for something that >> should really happen with consensus. >> > > I can see this but is it really unheard of? > It's not unheard of, but it's also extremely uncommon. And in my opinion, should be avoided - especially in cases like this - where the value associated with the RFC isn't overwhelming. In the grand scheme of things, removing short tags isn't going to move the needle for the popularity of PHP, definitely not in a positive direction anyway. It has mostly the potential to make certain folks feel better about the syntactical purity of the language - while at the same time making the upgrade process more difficult - in a world where one of our biggest challenges is that people don't upgrade frequently enough. > Because what prevent me from then re-openning the vote again if the vote >>> then fails? >>> >> >> Nothing really, other than common courtesy. >> I was even hoping that the RFC will be withdrawn given the number of nays >> from core devs, but that's of course something that is up to you. >> > > In all honesty I didn't check who votes for what as IMHO everybody is > entitled > to their opinion. > Of course everyone is entitled to an opinion, but not everyone is entitled to a vote. As I've said numerous times over the years, our voting system is flawed and provides voting privileges to folks who are not supposed to have voting privleges per the Voting RFC, simply because it was the simplest way to implement it at the time. It created a situation that has no parallels in the Open Source world, at least none I'm aware of. Open Source projects (non-commercial ones at least) tend to always be based on meritocracy. PHP is pretty much the only high profile project where someone who spend years of their time working on creating the project, has the same weight as someone who submitted a couple of patches or even didn't submit any patches at all. And no, it was never intentional - it's a flaw of the voting system that is only getting bigger and bigger as years go by - where the number of core devs stays roughly the same, but the number of folks with voting access grows larger and larger. And no, it's not that I think we 'saw the light' that all other OS projects don't see. Fixing it is simply a very challenging task that nobody has been up for thus far. > The problem I have with putting this again to a vote is that it feels > revote until the > outcomes is convenient to me. And going with this logic I feel I could say > let's > redo a vote to deprecate the var keywword as the last vote was 3 years ago > and maybe opinions have changed. It just end in more resentment IMHO. > Ther'e s fundametal difference between votes that were already implemented and went out, and something where the vote just ended a couple of days ago. Even more so given the fact that there were issues with the way the voting options were laid out that made them inconsistent with the Voting RFC and our rules, and might have influenced how people voted (in both directions). That alone should be sufficient grounds to redo the vote and do it properly. Zeev
