Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115835
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> <6126a723.1c69fb81.52e9a.a6f8SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <6126a723.1c69fb81.52e9a.a6f8SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 25 Aug 2021 22:55:42 +0200
Message-ID: <CADK1yXJd=Pfw6bu2cUhxFoCLykpfuw1B1eiiBst-ecVUWam2jQ@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004def5305ca687b19"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--0000000000004def5305ca687b19
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2021 at 10:25 PM Ben Ramsey <ramsey@php.net> wrote:

> Deleu wrote on 8/24/21 13:53:
> > 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.
>
> I don't understand how this proposal helps with this. If changes are
> necessary to accomplish a previously approved RFC, that means the RFC
> isn't fully implemented, so there are bugs, and bugs should be addressed
> using the normal bugfix process. They shouldn't require another RFC.
>
> If a change requires another RFC, that means something is being proposed
> that changes the behavior of a previous RFC (or adds to it). This is a
> new feature.
>
> Cheers,
> Ben
>
>
This is where looking at the Attribute RFC may be helpful. The approved
syntax was actually ambiguous and only discovered during implementation. A
secondary RFC to change the syntax was proposed. Was this secondary RFC a
new feature? Not exactly. Was it a bugfix? Not exactly either.
The point of a Refinement RFC is an attempt to address what Nikita said on
the other thread:

> As a meta note, I think it's important that we're open to minor changes t=
o
> new features during the pre-release phase -- it's purpose is not just
> implementation stability. In fact, we can fix implementation bugs anytime=
,
> but usually can't do the same with design issues.

Some design issues might require changes that are not necessarily a new
feature, but it's not a bug either. They may be able to be implemented
as-is, but is that the best decision for the project?

Again, let me state that whether Nullable Intersection Types is a new
feature or not is beyond the scope of this proposal. That is something for
Release Managers to evaluate and voters to decide. These guidelines help in
establishing a process to deal with design issues during implementation of
already-approved RFCs in a timely manner.

--=20
Marco Aur=C3=A9lio Deleu

--0000000000004def5305ca687b19--