Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105479
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.com>
 <CAOv67gsiva80KEhw7D2N2qKCz0gZvza30EDL7SZoJRPFsGoROA@mail.gmail.com>
 <0ec42fa9-77d1-a203-8425-e72fdd5071f3@korulczyk.pl> <06473788-a34b-f041-36e6-31d19d8dda4c@cubiclesoft.com>
 <59cafbfb-2bb0-468c-458f-74bcac780e0f@korulczyk.pl> <004c01d4f09f$880ac320$98204960$@roze.lv>
 <CAFPFaM+QwXpm-mfwRtbT2sPB_C-9wvPELVTV5dHvizgmfUjMnw@mail.gmail.com>
 <004401d4faa3$60f83700$22e8a500$@gmail.com> <2f922f17-bc7c-313a-8f77-122e861995be@lsces.co.uk>
 <5741936F-B1F4-43C7-B815-F9D8030AC7BB@koalephant.com> <e5c10f59-bde9-dadc-e837-266f870b6358@lsces.co.uk>
 <B392E7C8-BBAC-48D2-BBBA-3D7C7EFD9595@koalephant.com> <e702a5cc-9567-0591-8f5e-b14aef0766b7@lsces.co.uk>
 <CAAfnsFU1B61qaPRAh5uNTWMALcV5xmae0Yb1yY9+QaAGLVGx7A@mail.gmail.com>
 <49A4B76C-4C62-4CBE-BA20-FBE56CA29AB0@cschneid.com> <CADyq6sL7m=A=pA1rNBg_CFOoMtfCZn50AfALh9jtLHvn9NRzmw@mail.gmail.com>
 <609E93CF-099B-446C-AD28-04F1D802C9F0@cschneid.com> <CADyq6s+6Gqaa6Werc0Vn=gKWrrqC71+ry1rpsPEpq4BSE4wq_Q@mail.gmail.com>
 <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv> <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com>
In-Reply-To: <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com>
Date: Sun, 28 Apr 2019 13:26:46 +0200
Message-ID: <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Reinis Rozitis <r@roze.lv>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000750a405879575ef"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: george.banyard@gmail.com ("G. P. B.")

--0000000000000750a405879575ef
Content-Type: text/plain; charset="UTF-8"

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.
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

--0000000000000750a405879575ef--