On Sun, 28 Apr 2019 at 10:01, Zeev Suraski <z...@php.net> wrote: > On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r...@roze.lv> wrote: > > > Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > > votes make the difference. > > > > > At least for me, this definitely was the case. When I voted, it was > nowhere near clearing the 2/3 threshold. >
You must have voted on the same day the RFC went to voting. As the next day when I had a chat with Derick for his podcast both votes had cleared the 2/3 threshold, not with a big supra-majority but it cleared. And it was above the threshold for the rest of the voting period everytime I checked (so mas every two days). So are we now going to need to do daily email during the vote to inform what is the voting status of our RFC so everyone is in the loop? When you can simply just check the RFC page or look at PHP RFC Watch? [1] > 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 (and seems that is where people disagree as more people vote for the removal without the deprecation notices which seems to point this is the issue) which in hindsight is a stupid thing to do, but I would have loved that people point out to this specific issue (and the voting structure) during the discussion or even at the beginning of the vote. But basing my self on the vote to remove the short open tags in PHP 8, which cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes without any "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes "only" needs two (2) votes to be on the 2/3 threshold. So to my understanding of how the RFC process works there would need to be at least three (3) "NO" votes for the deprecation to fail (which I think we can all agree how I went about is crap and I'm open to changing how this gets implemented as seen on the other ML thread and the PR) and at least seven (7) "NO" votes for the removal vote. Process wise we're in a bit of an unchartered territory here, but I don't > think we should let the headache involved with figuring out how to reverse > this decision force us to impose this on our users. It's better to go > through this unpleasantry now than deal with the backlash later. > 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. Moreover going about how Twitter [2] reacted (which isn't necessarely a good metric) it seems a *vast* majority is in favor of this change. > George, please consider reopening the vote for an extra week. That is > probably the simplest way to move forward from a process standpoint. > > Zeev > I can consider it but I am really not keen on it. Because what prevent me from then re-openning the vote again if the vote then fails? What happens if the deprecation vote fails but not the removal? Would this imply changing how it is deprecated which is literally the topic of the other thread without any more voting which I'm totally open to how it is changed? I don't even mind still having a compile error in PHP 8 when it sees the token as I said before I don't really care that much about the timeline. Best regards George P. Banyard [1] https://php-rfc-watch.beberlei.de/ [2] https://twitter.com/nikita_ppv/status/1121040700156579840
