Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105503
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: Mon, 29 Apr 2019 10:17:12 +0200
Message-ID: <CAF+90c-Qo6_MDyjmUyavcB_iLvh-0J=NyZkPiRjmyHv7Mp2e+g@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Reinis Rozitis <r@roze.lv>, "G. P. B." <george.banyard@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004f643e0587a6ea5b"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000004f643e0587a6ea5b
Content-Type: text/plain; charset="UTF-8"

On Sun, Apr 28, 2019 at 10:02 AM 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.
>
> 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

--0000000000004f643e0587a6ea5b--