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. (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. > 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. > 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? > 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. > This may well be true but by the same argument I can say that a lot of people are for this even tho they didn't express this as much as those against it. > 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. > The problem is if we don't address it now it will be even more complicated when PHP 9 rolls around and then again. I still believe these short tags are a legacy oddity that should be removed. 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. > 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 > 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. On Sun, 28 Apr 2019 at 21:46, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > > On 4/28/19 4:52 AM, Benjamin Morel wrote: > >> I don't even mind still having a compile error in PHP 8 when it sees the > > token > > I thought one of the arguments for the whole enterprise was to enable > <?xml to pass through PHP? Isn't that what the RFC was claiming? So this > obviously won't work with this solution. And the "parser simplification" > claimed by RFC would also not happen, I imagine, since there's still two > separate tokens. So we are already out of at least half the reasons > original RFC has claimed... > -- > Stas Malyshev > smalys...@gmail.com Oh good to have you onboard for the initial RFC and remove it with PHP 8. I suppose the discussion is closed then in this case. :) Best regards George P. Banyard
