Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105612
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=HWf8s7if/IZvqvGC+tdApQK0/ig9B/alS8n1wJby4JVVjVaa43AmYHiN8lisnR
	GKoZ/FkXJUnjluVc4fSN2K9sZ68rZrcB0Y64Vir+H7jRes7mGciRJoREmjoi3nMB
	Sc+EMkoMjMC9jckoRJlmSfepC7tuWrbEkn9lXlFhKUBks=;
MIME-Version: 1.0
nsFUhMKf1YYuT1eCF65yfX+FjNAcr_MyAiPM-fiPawTKDLQ@mail.gmail.com> <CAFPFaM+X5FXuGtK1snKML+aJt1bceUuTye87qMo5vc_8Yxy30A@mail.gmail.com>
In-Reply-To: <CAFPFaM+X5FXuGtK1snKML+aJt1bceUuTye87qMo5vc_8Yxy30A@mail.gmail.com>
Date: Tue, 7 May 2019 14:28:20 +0300
X-Gmail-Original-Message-Id: <CAJHtznw4Z52qCKeF9V=XfXvS5yKAJ0deagjO7hn7CZCZhWKeAQ@mail.gmail.com>
Message-ID: <CAJHtznw4Z52qCKeF9V=XfXvS5yKAJ0deagjO7hn7CZCZhWKeAQ@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Peter Kokot <peterkokot@gmail.com>, Stanislav Malyshev <smalyshev@gmail.com>,  Derick Rethans <derick@php.net>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000052319a05884a849b"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: zeev@php.net (Zeev Suraski)

--00000000000052319a05884a849b
Content-Type: text/plain; charset="UTF-8"

On Fri, May 3, 2019 at 1:21 AM G. P. B. <george.banyard@gmail.com> wrote:

> Evening internals,
>
> I am not going to go into the details of every email which got sent in the
> past two days as I am busy with Exam revision.
>

I was also kind of busy, but more importantly I wanted to wait a bit before
I reply - as my previous quick-turnaround reply was offensive to you.


> Main take away that I got from the previous emails:
>
> 1. No discussion:
> It is indeed true that there hasn't been a lot (to not say none) of
> discussion after the announcement but I hadn't gotten any reply after I
> replied to the people who commented on it so, in my mind if there is no
> more discussion I don't see why I should have waited longer to bring the
> RFC to a vote.
>

That's understandable, but I believe there's a different explanation here.
I hope you won't find it too offensive - but in my mind, the RFC was so off
the charts a 'no', that I didn't think it stood a chance, and did not
bother participating in it.  I know several others who feel exactly the
same way.  Most of the discussion revolved around how easy it would be to
work around the BC break we'd be introducing, and almost none of it was
about justifying the BC break in the first place.  Elements which were
obviously wrong in the RFC - such as some of the motivation ("Simplifying
the parser" - simply wrong) as well as the implications (potential for
wholesale disclosure of code) - weren't discussed even one bit.


> 2. Voting structure:
> If the voting structure was that confusion, sending a message to the ML
> like Peter Cowburn (@salathe) did would have allowed me to stop the vote
> fix the structure and bring it back to a vote.
>

Perhaps.  But the voting results make it clear beyond a reasonable doubt
that the voting options were not clear - as in fact, we were a couple of
votes away from creating an impossible outcome (remove in 8.0 without first
deprecating in 7.4).  Like I said, while it's impossible to determine
whether this would have materially affected the results or not - it's
obvious that there was confusion because of the way the vote was laid out.

Saying that it was confusion after the vote is ended is IMHO just a way to
> not assume responsibility and get your way because the result doesn't
> pleases you.
>

It goes far beyond displeasing me.  I think Stas (Stanislav) summarized it
in the best possible way in his replies.  I've had my share of RFCs whose
outcome displeased me - but never one that failed to clear the most basic
requirements for a healthy process.  I want to make it clear - this is not
entirely or even primarily your fault.  The issues with the voting options
should have been brought up much earlier in the process, and it's shameful
that the discussion on internals was clearly remarkably shallow before this
went to a vote.  Neither of these are your fault, but these are faults that
need to be fixed.


> No I don't see the rationale that saying the removal vote isn't an
> implementation detail because from my perspective it is.
>

Something that will effect hundreds of thousands of developers is not an
implementation detail.


> Because if not wouldn't the secondary vote on the JIT [1] RFC also not be
> an implementation detail in this case?
>

I admit you have a point.  Strictly speaking, it should have been in two
separate primary votes - where we first vote for the 8.0 question, and then
(in a separate, followup RFC) vote for the whether to also include it in
7.4.
However, there are several key differenating factors:
1.  Unlike the short tags RFC, there was in-depth discussion around the JIT
patch on internals - and in particular the merits as well as the
disadvantages of including it as experimental in 7.4 was thoroughly
discussed.  At least to those who read the discussion - it was clear what
the key question was and what the secondary question was, and the
dependency between them (no way we're going to include it as experimental
in 7.4 if we don't plan to roll it out in 8.0).
2. When you look at the voting results, it's clear that this understanding
extended to virtually everyone who voted on the JIT RFC.  The only two
people who voted against inclusion in 8.0, also voted against inclusion in
7.4.  Put another way, there's not a single person who voted for inclusion
in 7.4 while voting against inclusion in 8.0.  The dependecy was clear.
3.  Unlike the voting question at hand (in the short tags RFC), the
implications are far reaching (in fact, a lot farther reaching than anybody
initially realized) - inclusion in 7.4 has virtually no implication on
anybody that's not proactively trying to use it (which based on our
experience with past experimental features, isn't a great deal of people at
all).
4.  The results of both questions in the JIT RFC were extremely clear cut.
One at 96% in favor (clear consensus in favor), and the other 67% against
(clearly very very far from consensus or even majority).  Even if somebody
was confused by the voting questions, it's unlikely to have made a
difference one way or another.  Not so with the short tags RFC, which
either barely or narrowly cleared the mark(s).

That said, if anybody believes that there was any confusion with the JIT
RFC voting options, we can redo the votes on them (as two separate votes).

Even though you could say how it was presented it is not a secondary vote
> but then you can also considered it as a primary vote, and having multiple
> primary votes in an RFC is allowed per the Voting RFC [2].
>

There are two issues with this:
1.  It was in fact presented as a secondary vote.
2.  Placing these two primary votes in the same RFC doesn't go against our
RFC rules, but it does go against our deprecation rules - where we always
deprecate features before removing them.  The right way to do the voting
options on this RFC is actually dividing it to two separate votes - first,
are we deprecating this feature?  Secondly, if and only if we decided to
deprecate it, do we remove it right away in 8.0, or keep it for now given
the very short time between deprecation and removal.  Also, the 2nd RFC
should detail the right way of handling the removal (error instead of
silently ignoring).

And if even then this doesn't seem right just render void the secondary
> vote, no need to render void the whole RFC as the primary vote does respect
> the Voting RFC.
>

I disagree.  This RFC as a whole is incompatible with the Voting RFC, and
it's clear that people were confused with the voting options and the
dependencies between them.  It may have affected both the way people voted,
and even whether or not certain people voted in the first place.  The only
way to fix it, is to redo the vote properly - ideally after we actually
discuss the merits of going through this BC break in the first place.

Zeev

--00000000000052319a05884a849b--