Re: [PHP-DEV] Guidelines for RFC post feature-freeze

This is only part of a thread. view whole thread
  115822
August 25, 2021 16:58 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le mar. 24 août 2021 à 21:09, Derick Rethans <derick@php.net> a écrit :

> 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 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. > >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
  115827
August 25, 2021 18:16 derick@php.net (Derick Rethans)
On 25 August 2021 17:58:55 BST, Nicolas Grekas grekas+php@gmail.com> wrote:
>Le mar. 24 août 2021 à 21:09, Derick Rethans <derick@php.net> a écrit : > >> 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 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. >> >> That's where I disagree already. The nullable intersections RFC isn't a >> refinement, it's a new feature. > >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".
You're wanting to add a new feature during feature freeze, so yes, I wouldn't have allowed it.
> 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.
Yes, suggesting tweaks to existing features is fine, up to a certain point. Introducing new ones is not.
> 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.
The RFC was "pure intersection types", with a scope decided by its author. That RFC says no Union types.
>Maybe it's obvious for you in this case, but others shouldn't be denied the >right to discuss the topic.
Discuss whatever you want, but that doesn't mean that a new feature RFC should be allowed during a feature freeze.
>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,
I disagree that it does. Union intersection types is something that the pure intersection types RFC ruled out.
> 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.
This is all moot, because that RFC hasn't been passed. I also don't think it's necessary. If you want to disregard the concept of a feature freeze, that's fine too. But not in the PHP project. Cheers Derick