Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102707
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <c397cf94-a713-6f33-0696-5e35db3dbae5@gmx.de>
References: <CAF+90c_+GZNrV1SC9q=Y3C=L3LMnoXX7J3zK6=kS9-sMXHZZow@mail.gmail.com>
 <CAJW__o3BsiUoMwxhwPwBwY+OTPt1f=O6aQsHBot-Dat3MRCBpg@mail.gmail.com>
 <CAF+90c_x5ad+oAdPRKaEasMGAUyK+UELHnPEai-aOAPquKVySA@mail.gmail.com>
 <5153610d-abed-b21a-ec55-56d967128cae@gmail.com> <CAJW__o3smiKaCQOFSYqtQzPZJb2=iuR0RojWqshoOadFD7-vHg@mail.gmail.com>
 <CAF+90c8z-r4aL8ZVOCU+3V4tc3R2dhWXbDgXc+sOy3Cnb6i=sg@mail.gmail.com>
 <CAJW__o0EEABZDzg9CbPgRfY5u_DUL4+fUbbn3VDzuK0nseeiOQ@mail.gmail.com>
 <CAJW__o1wjqVNgsbGQvKNYBdT8NUa+aJjiOsRToP6OcnQybxN_w@mail.gmail.com>
 <CAF+90c8v15GXSCofiq4_s51_+fQguHgJF=4OVGiKOYF1BgkaCA@mail.gmail.com>
 <cfc6ed92-3062-8026-ac2d-c43061918ef9@gmx.de> <CAESVnVr0oB2vF793hLqi6q2ELOJMJ6mjpp5B_ZsXj2WEVNmE9A@mail.gmail.com>
 <017101d41815$95118440$bf348cc0$@gmail.com> <CAF+90c8Y4PAi+PCGnHV_xf3_3HaY8yc8Ww3nyur88UqX_xP+Kw@mail.gmail.com>
 <c397cf94-a713-6f33-0696-5e35db3dbae5@gmx.de>
Date: Tue, 10 Jul 2018 14:45:39 +0200
Message-ID: <CAF+90c-yG9sWLj847-GBLe=x9ft80O=+aq7c2DZai3xmtzpP1A@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Zeev Suraski <vsuraski@gmail.com>, Sara Golemon <pollita@php.net>, 
	Kalle Sommer Nielsen <kalle@php.net>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ec5c770570a481f2"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ec5c770570a481f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 10, 2018 at 12:35 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 10.07.2018 at 09:36, Nikita Popov wrote:
>
> > To make sure there are no unreasonable expectations involved in this
> > decision: If this feature will not go into PHP 7.3, then it will in all
> > likelihood go into PHP 7.4 instead. I think I can safely say not just o=
n
> > behalf on Bob and myself, but also on behalf of the wider PHP community=
,
> > that we are not willing to sit on this feature for 2.5~3 years until a
> > hypothetical PHP 8, even though it is essentially ready *now*. Of cours=
e,
> > this is not my decision to make, but as Sara put it, that's the writing
> on
> > the wall. By deciding not to include this in PHP 7.3, we are essentiall=
y
> > making an implicit decision that PHP 7.4 is going to be a relatively
> > ordinary feature release rather than a deprecation-only one. (Which is
> fine
> > by me really, I don't like the idea of a release that's all stick and n=
o
> > carrot.)
> >
> > Finally, given the current situation where we have a whopping five (!!)
> > RFCs with votes ending the day before feature freeze, I'd say postponin=
g
> > the schedule is a good idea even without any consideration to typed
> > properties. Just landing something like the comparison overloading RFC =
on
> > the day of feature freeze is not going to be pretty. We are quite
> obviously
> > rushing things right now, and I don't think keeping to some otherwise
> > arbitrary date is worth that.
>
> Good point!  Thus, I suggest to put in *one* additional alpha (i.e.
> postponing feature freeze by two weeks to 2018-07-31) in any case, have
> the vote on =E2=80=9CTyped Properties=E2=80=9D starting soon with explici=
t options which
> version these should be merged into, and if there will be an option to
> target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to
> insert yet an additional alpha5.
>

That sounds like a very reasonable approach to me.

Anyhow, I strongly suggest to amend our voting and release rules to
> avoid such situations in the future.  Ending any vote one day or a few
> days before feature freeze should simply not be allowed (unless the RFC
> targets another version).  And there should be clear rules which
> circumstances warrant or allow to postpone feature freeze, and who's
> decision that is.
>

Ugh yes. A hard rule that no new RFCs targeting the branch can be submitted
4 or 5 weeks before the feature freeze would be reasonable and would avoid
this mess in the future. Especially if could get an announcement about the
approaching "RFC freeze" a month or so in advance.

Nikita

--000000000000ec5c770570a481f2--