Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105481
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=z5FOAnsJHpgvKPdAujGJoFk6QZk2lgilt8wL6FsFTMjO2cqlX6VtillE4/Ljmx
	Hk9sojNXMUeQxR/E960/5EOrj/SLvsxE0fhdmXEViz+Rbny0abbXGbZ4BvJgVTvh
	SQsWDDnt6jr5rMC90i2dOsVqjefXRNS7q2vDWbPpZQRW0=;
MIME-Version: 1.0
l.gmail.com> <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv> <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com> <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com>
In-Reply-To: <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com>
Date: Sun, 28 Apr 2019 15:35:50 +0300
X-Gmail-Original-Message-Id: <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
Message-ID: <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Reinis Rozitis <r@roze.lv>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001d302f058796693f"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: zeev@php.net (Zeev Suraski)

--0000000000001d302f058796693f
Content-Type: text/plain; charset="UTF-8"

On Sun, Apr 28, 2019 at 2:27 PM G. P. B. <george.banyard@gmail.com> wrote:

> On Sun, 28 Apr 2019 at 10:01, Zeev Suraski <zeev@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

--0000000000001d302f058796693f--