Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115791
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
Date: Tue, 24 Aug 2021 20:53:57 +0200
Message-ID: <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000075bb1405ca52a8cc"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--00000000000075bb1405ca52a8cc
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 24, 2021, 19:28 Derick Rethans <derick@php.net> wrote:

> On Mon, 23 Aug 2021, Deleu wrote:
>
> > We recently had the Nullable Intersection Types RFC process in an
> > unconventional way starting a new RFC post feature freeze. If memory
> > serves me right, another similar incident happened with the Attributes
> > RFC which had a syntax that could not be implemented without a
> > secondary RFC [1] and went through a secondary RFC which proposed a
> > different syntax [2].
>
> I find this comparison disingenuous.
>

I want to state that I had no intention to compare the RFCs or even bring
their merits into discussion. What I intended to show is that we have 8.0
which had an RFC that would classify as Refinement RFC and 8.1 again having
another RFC that also classifies under the same category. Their merits are
left for their own discussion and their own voting.

The proposal is rooted in making it easier for release managers and rfc
authors to refine code changes that may or may not be necessary to
accomplish a previously approved RFC.

>

--00000000000075bb1405ca52a8cc--