On Sun, Apr 28, 2019 at 2:27 PM G. P. B. <george.bany...@gmail.com> wrote:
> 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. > That's definitely possible. I don't really remember, even though I do remember there were more than a handful of votes already registered. > 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] > I think a 24hr reminder going to internals is probably not a bad idea, but that's beyond the scope of this discussion and it's obviously not your fault for not sending it, considering one was never required. > 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. (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. > That's not how I understood the vote - although honestly, I found the vote layout to be a bit weird. There are are two issues here: 1. Secondary votes only kick in if the primary vote passes. They're also defined as votes where you only need a simple majority for one of the options. 2. The two questions are, in fact, one and the same. Removing a feature in a major version requires that we first deprecate it in a mini version, in other words - we can't remove something in 8.0 in case it's not first deprecated in 7.4. I admit I found this confusing that the two votes were separate, but the way I understood it, is that we may actually deprecate it at 7.4, without actually removing it at 8.0, but just keeping it deprecated. The other way around (removing it in 8.0 without first deprecating it in 7.x) is against our rules. 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. > 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. > It is, indeed, not a very good or even meaningful metric at all. The folks which are likely to care about this are almost definitely severely under-represented both here and on the dev cycles on Twitter. > I can consider it but I am really not keen on it. > I'd sincrerely appreciate it if you did. I'm not fond of fighting windmills, even less so nowadays than in the past - but I really think we're making a painful mistake for virtually no gain, and I'm pretty sure I'm not alone in thinking that. Ultimately, nothing in the RFC is new compared to what we knew back in 1998 when we decided to have short open tags. There are no new developments that make it more relevant today than it was back then - if anything, XML is a lot less important today than it was back then (when it was all the rage). And unlike 1998, the cost assocaited with deprecating it now is tremendous. So even if we can argue whether we took the right decision 20 years ago - there's really no new grounds to reopen that decision today. 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. 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. > I think the real question this RFC raises is whether we want to deprecate <? There are several valid options: - Do nothing (which probably gets my vote) - Deprecate it in 7.4, and remove it in 8.0 - Deprecate it in 7.4, and error out over it in 8.0 - Deprecate it in 8.0, and figure out what we want to do with it as we gear towards 9.0 (which would give us time to gauge the feedback before taking decisions - something that won't really be possible with 7.4/8.0 given the short timelines) What I don't really think is a possibility is removing it (one way or another) in 8.0 without first deprecating it in 7.4 (which again, is what I found a bit confusing about the vote options). I would consider restructuring the questions in a different way than they currently are and restart the vote: Primary Question - Deprecate short open tags yes/no (requires 2/3 majority) Secondary Question - which version 7.4/8.0 (simple majority) Secondary Question - what to do when we remove it - silent removal, error, something else? (simple majority) Thanks, Zeev
