Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115831
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241832420.2773@singlemalt.home.derickrethans.nl> <61269335.1c69fb81.b4c18.645cSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <61269335.1c69fb81.b4c18.645cSMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 25 Aug 2021 21:35:29 +0200
Message-ID: <CADK1yXJRJHch8YSLNBrv8FP_s0orUQk5y5Wp+3VWzTLUDSV0Pw@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>, Derick Rethans <derick@php.net>, 
	Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000073f79105ca675cd7"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--00000000000073f79105ca675cd7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2021 at 9:00 PM Ben Ramsey <ramsey@php.net> wrote:

> Derick Rethans wrote on 8/24/21 12:35:
> > On Mon, 23 Aug 2021, Deleu wrote:
> >
> >> In order to not be empty-handed, I started a gist that can be seen as
> >> the starting point for this discussion, available at
> >> https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105.
> >
> > 4. A Refinement RFC MAY be proposed with a schedule for ending it's vot=
e
> > after feature freeze if at least one Release Manager approves it.
> >
> > IMO, they should have consensus.
>
> Agreed. I wasn't aware of the Nullable Intersection Types RFC myself
> until this week, and that's on me. I would probably have disagreed with
> allowing it.
>
> Cheers,
> Ben
>
>
This was the primary reason why I wrote item 4 like that. I feel that it
would be unreasonable to expect every release manager to be aware of every
detail at all times. They are volunteers that may need some time off, be on
holiday or simply unavailable. In the absence of one of the Release
Managers, another one can grant the right for a Refinement RFC. Such a
decision would be partially temporary because once all Release Managers are
aware of the events they would then be able to make an unanimous decision
of rescinding the grant if that's what's best for the project. A Refinement
RFC Author has to be willing to take such a risk.

On Wed, Aug 25, 2021 at 8:52 PM Ben Ramsey <ramsey@php.net> wrote:

>
> I would be in favor of an "informational" RFC rather than a "policy"
> RFC. An informational RFC can define terms, such as "refinement RFC" and
> "feature freeze," without burdening the project with more policy overhead=
.
>
> Cheers,
> Ben
>

Do we have the concept of an informal RFC? As far as I could see there are
language changes targeting a specific version and policy and processes [1].
I could not find another type of RFC to be proposed.

[1] https://wiki.php.net/rfc

-----------------------------------

On Wed, Aug 25, 2021 at 8:16 PM Derick Rethans <derick@php.net> wrote:

>
> >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 definitio=
n
> >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.
>
> Cheers
> Derick
>
>
I believe this discussion goes to show that Release Managers judgement call
is the key aspect of these events and will continue to be. Ultimately it
will depend on who the release manager is and how the idea is proposed.
This RFC would not change this, but explicitly state the steps and the
possibilities. If an RFC author cannot convince Release Managers that their
proposal falls under Refinement RFC, they will be denied the chance to make
their case after feature freeze, as they already are. On the other hand,
even if a Release Manager strongly objects to a proposal, they still have
the ability to put it to a vote if they believe it to be a refinement
proposal.

--=20
Marco Aur=C3=A9lio Deleu

--00000000000073f79105ca675cd7--