Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115822
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
 <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com> <C7EF7C8B-A617-4C44-AAD5-B970098EC5AB@php.net>
In-Reply-To: <C7EF7C8B-A617-4C44-AAD5-B970098EC5AB@php.net>
Date: Wed, 25 Aug 2021 18:58:55 +0200
Message-ID: <CAOWwgpnu1Zgigx8xwsnEYufC+=cp94fescFvOpMYxY_U50_uNg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Deleu <deleugyn@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001dcc8705ca652b8e"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000001dcc8705ca652b8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 24 ao=C3=BBt 2021 =C3=A0 21:09, Derick Rethans <derick@php.net> a =
=C3=A9crit :

> On 24 August 2021 19:53:57 BST, Deleu <deleugyn@gmail.com> wrote:
> >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 Attribut=
es
> >> > 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 brin=
g
> >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.
>
> That's where I disagree already. The nullable intersections RFC isn't a
> refinement, it's a new feature.
>

Hello Derick,

Can you please clarify what you want to express here? Your insistence in
repeating that statement makes me read this as: "the nullable intersections
RFC was not legal". If that's the case, I find that deeply disturbing,
because I need to be allowed to discuss not-yet-released features during
the freeze period. Whether an RFC should be considered as a new feature
should be the end of the discussion, not the abruptly-closing start. The
reason is that there is no precise definition of what "a feature" means.
Maybe it's obvious for you in this case, but others shouldn't be denied the
right to discuss the topic.

I think that we can reach a common agreement by working on the definition
of what we mean by "Refinement RFC".

Marco's gist defines them as "An RFC proposing changes, amendments,
adjustments to the language while refining an unreleased change that has
been approved." I'm sure we can improve it, but I mostly agree with this
statement. My RFC falls under this definition, and that should be enough to
end the debate around whether any particular post-feat-freeze RFCs are
legal. I think we should focus our efforts on improving this definition,
and move forward.

Nicolas

--0000000000001dcc8705ca652b8e--