Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105521
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=B4HOGLuhCqQhwk0WP6tIjwGD1xNNiJuo6yedjOO9xu99l3OrcQJQh1i458+Zue
	LuwVglc4X4qtigQg9+41Bv5FJ+RCdXm3sajtjdRRTIxhmsHOiQNB+XG0MSJsmDNH
	n9+/b+Kxx66L208kUwDP1WGER+4Y0EyrdESotl718Ho0M=;
MIME-Version: 1.0
t6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com> <CAF+90c-Qo6_MDyjmUyavcB_iLvh-0J=NyZkPiRjmyHv7Mp2e+g@mail.gmail.com> <CAJHtznxKdeb4Zz=wBDFkEDNVChiGZGYDphxW9YLQK-QbNG83nA@mail.gmail.com> <CA+kxMuTTOyOQR6Afw6eZ+K+yy4yBhw2d_ZtrtZ-V-nv5Bsi8ag@mail.gmail.com> <CAJHtznyuX+mXeBXcEiGfdWW5usBz3e5k6ytbVHwdJ4LsoN9-og@mail.gmail.com> <CAFPFaM+ttJwnMF45YvXnx3xM2XqSeaP_GVmDCup0pjL06gxyjw@mail.gmail.com> <CAJHtznxELLj_8TzCukQtV5_BV430XH851VMPogWrMgDKZspM_g@mail.gmail.com> <CAFMT4Npg50hk6eaUs126E8RjwpNOYwv6hoOYKtPFb3sWTYzJsg@mail.gmail.com>
In-Reply-To: <CAFMT4Npg50hk6eaUs126E8RjwpNOYwv6hoOYKtPFb3sWTYzJsg@mail.gmail.com>
Date: Tue, 30 Apr 2019 21:14:28 +0300
X-Gmail-Original-Message-Id: <CAJHtznzZREQeab_xdHWLO+d+dEa1sRn0JfdUg+jPXdkR6+_5_Q@mail.gmail.com>
Message-ID: <CAJHtznzZREQeab_xdHWLO+d+dEa1sRn0JfdUg+jPXdkR6+_5_Q@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: PHP Internals List <internals@lists.php.net>, "G. P. B." <george.banyard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ec35730587c35f4f"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: zeev@php.net (Zeev Suraski)

--000000000000ec35730587c35f4f
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 30, 2019 at 7:03 PM Levi Morrison <levim@php.net> wrote:

> On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski <zeev@php.net> wrote:
> >
> > On Tue, Apr 30, 2019 at 2:14 PM G. P. B. <george.banyard@gmail.com>
> wrote:
> >
> > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <zeev@php.net> wrote:
> > >
> > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com>
> > >> wrote:
> > >> > Please stop doing this.
> > >>
> > >> I will gladly do so, once the project starts behaving responsibly
> again.
> > >>
> > >
> > > Honnestly, this comment right here Zeev just makes me want to not
> > > compromise at all.
> > > I think you seriously lost any hope there was that I'm going to put
> back
> > > this to a vote.
> > >
> >
> > In retrospect, I should have waited for Dan's insulting message to wear
> off
> > before replying to it.
> >
> > The fact the RFC included a confusing secondary vote, that was defined
> > against our RFC rules and may have been misunderstood by folks who voted
> > (and consequently may have resulted in different outcomes) - is
> sufficient
> > grounds to disqualify this vote and require a restarted vote on a fixed
> RFC
> > (that can include the amendments you have in mind to make the 8.0
> behavior
> > different from what the RFC proposed).
> >
> > Zeev
>
> I read our voting rules, checked with a few people, and thought about
> it for a while, and I still do not know what rule breakage you are
> referring to. How did this supposedly break our voting rules? If you
> want any support on disqualifying this RFC, you need to clearly state
> the violation.
>

The Voting RFC states:

"Additionally, an RFC may have secondary votes, which are used to *decide
implementation details*. "   (emphasis added)

The RFC in question states:
"Secondary vote: Remove PHP's short open tags in PHP 8.0."

This is not an implementation detail or even remotely one.  It's makes a
huge difference, arguably a lot bigger than the primary vote (which can be
fairly easily ignored by end users).

This is not a technicality.  I found the voting options very confusing, and
I'm sure I wasn't the only one.  In addition, I found it very weird that
many folks voted NOT to deprecate this feature in 7.4, but voted in favour
of removing it in 8.0 - which doesn't go against any of our RFCs (at least
if my memory serves me right), but does go against the way we've been
handling deprecations in the last ~15 years - you never remove a feature
without deprecating it first.  So in addition to stating a secondary vote
for something that had to be a primary vote - the 'original' primary vote
(deprecate in 7.4) is in fact an inherent requirement if the secondary vote
passes - but judging from people's votes, it's clear it wasn't properly
understood.  George has a reasonable interpretation as to what this meant -
but it's just one possible interpretation.

Ultimately, the voting decisions were flawed and against two of our rules
(one written, and one de-facto) - which means that needs to be fixed and
redone.  It's impossible to know what kind of impact laying out the voting
options properly would have had (it goes in both directions, by the way -
it may have resulted in a higher majority - or a lower one, pushing it
below the threshold).

On the substance level - I think it's clear even to the pro-deprecation
crowd that this RFC was created in haste.  There was very little discussion
over it, so little that the fact that the fact that outright removing short
tags in 8.0 (as opposed to turning them into errors) would have
catastrophic consequences wasn't even discussed.

I've heard from several folks that the right way to address this is with a
new RFC that will supercede this one.  I agree, but it should be the
authoritative RFC with the current one being annulled - given the flawed
voting options.  We need a new RFC that fixes the flaws of the current one
- both in terms of substance (8.0 behavior) and voting options.

Zeev

--000000000000ec35730587c35f4f--