On Sun, Apr 28, 2019 at 10:02 AM 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. > > 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. >
Keep in mind that for example the FFI RFC passed with something like 60% majority, even lower than this RFC. I think you're cherry-picking a bit here, when it comes to what should and shouldn't pass ;) 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 think that process-wise (if we can't agree on landing some variation of this, as I've suggested in a separate thread) the right thing to do would be to draft a new RFC that overrules this one. It can lay out the new arguments that have come up in the meantime in an orderly manner and be voted separately. Nikita
