Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115795
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CF38091C-FE8E-4234-970A-4A16B1046EA4@gmail.com>
In-Reply-To: <CF38091C-FE8E-4234-970A-4A16B1046EA4@gmail.com>
Date: Tue, 24 Aug 2021 14:29:56 -0500
Message-ID: <CAESVnVqGFMZzwGj+YuuW_FJSkbn88mCVWtYPx4S26+UE8Knfiw@mail.gmail.com>
To: Tobias Nyholm <tobias.nyholm@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000048c05905ca53293f"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: pollita@php.net (Sara Golemon)

--00000000000048c05905ca53293f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm <tobias.nyholm@gmail.com>
wrote:

>
> Situations like this often requires a judgement call rather than somethin=
g
> that could be defined as a policy.
> I suggest the release managers always should be in agreement before a RFC
> is created during a =E2=80=9Cfeature freeze=E2=80=9D. If the release mana=
gers agree that a
> change can be added, then the discussion and the vote should not consider
> =E2=80=9Cif it is too late=E2=80=9D or =E2=80=9Cthis is rushed=E2=80=9D. =
I think we can trust the release
> managers to make the correct desiccation without an extra policy.
>
>
Agreed, and I would say that we DO have a policy.  The policy is that the
RMs make a judgement call in the moment.  I still think the attributes
syntax was appropriate to make an exception for (given it was a new feature
and this would be our last chance to refine the syntax), as was the
nullable intersections case (the additional change to the engine was
trivial, while providing notable benefit).  So I would say we don't need a
strong policy saying "exceptions in these cases only".

However, I'm all for some definitions of best practices and considerations
to take into account to make the decision making process more predictable
and less arbitrary.

TL;DR - This RFC sounds like a great idea, assuming appropriately scoped.

-Sara

--00000000000048c05905ca53293f--