Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106406
To: Peter Kokot <peterkokot@gmail.com>, Andrey Andreev <narf@devilix.net>
Cc: "G. P. B." <george.banyard@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAPKYkKxHkQojFnCs09htRFvTrV_SReQV7YVo6RxRSmuN9H_Q0w@mail.gmail.com>
 <CALKiJKrXatW9Va0bjsUQD+TCCge=HcMzyV8Uf+rq+_s9xoyyuQ@mail.gmail.com>
 <CAFPFaMJKq7rqY0ZSPuimWVTY8ZZc=jXJS3__fNRnvBfp+W3PXg@mail.gmail.com>
 <CAPhkiZy-5Z0CLMUCZ_0OKaUrONrbVfZztfvRcOMUvjEFRp9Xqg@mail.gmail.com>
 <CAAfnsFU_ROGbfPqo33xgVH=nZ_6D7bS_4NkC8YXnOF45_82Z6A@mail.gmail.com>
Message-ID: <4b6de194-b4a5-aa48-723e-1700b4cf8421@gmx.de>
Date: Wed, 7 Aug 2019 11:39:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAAfnsFU_ROGbfPqo33xgVH=nZ_6D7bS_4NkC8YXnOF45_82Z6A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 07.08.2019 at 10:44, Peter Kokot wrote:

> On Wed, 7 Aug 2019 at 09:28, Andrey Andreev <narf@devilix.net> wrote:
>
>> On Tue, Aug 6, 2019 at 8:20 PM G. P. B. <george.banyard@gmail.com> wrot=
e:
>>
>>> This RFC supersedes the previous one as stated in the the RFC itself :=
 "
>>> This RFC supersedes the previous one and proposes a different deprecat=
ion
>>> approach." meaning that the previous one is void.
>>> I don't know why this is ambiguous and needs to be said once again.
>>
>> As far as I know, there's been no vote to cancel the previously
>> accepted RFC, so ... even though I didn't like the outcome of it, I
>> don't understand how it is just made void now. It's pretty easy to
>> understand the ambiguity.
>>
>> I won't be voting on this one due to all of this.
>
> Yes, last time I was asking this, there was a clarification that
> certain people from the group internals can veto particular RFC. So, I
> think that this is the case here.

I'm not aware of *any* veto rights regarding RFCs.  As I understand it,
this RFC has been put to vote again, because the first version had some
problematic details, and by courtesy to cater to the clamor raised after
the voting had finished.

Thanks,
Christoph