Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115787
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 13:26:15 +0200
Message-ID: <CADK1yXKGVqg6mnUHMVJKXvqC27DiH_kqsK0Lc4PG1Zo9JH1kJA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000008d04605ca4c696b"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--00000000000008d04605ca4c696b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> 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.
>

That would be a violation of voters rights. They are allowed to vote no
without any reason whatsoever. Not having enough time to thoroughly discuss
something or feeling like the RFC is being rushed due to feature freeze is
a perfectly valid concern to vote No. I also disagree that 1 or 2
individual(s) (Release Managers) should hold power on influencing people's
vote.


On Tue, Aug 24, 2021 at 8:08 AM Pierre Joye <pierre.php@gmail.com> wrote:

> Hi Marco,
>
> It is a very good text, thank you!
>
> It is also much needed, generally speaking. What I would add is about
> what is allowed to begin with. I would rather restrict to fixes only.
>
> The other issue, which is the one Nicolas suffered from, incomplete
> addition to begin with. Incomplete in the sense of, "We add feature A,
> but behaviors A1 and A2 are not supported and can be done later".
>
> Best,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>

I believe that the concern you raise here would be categorized as outside
the scope of what I intend to propose. The RFC process is in place to
handle such cases. It may or may not need improvement, but the bottom line
is that if enough voters agree with an RFC, even if everyone agrees that it
is "incomplete" it's still an approved change for the language. A
Refinement RFC policy would extend the time available to deal with
implementation consequences found after the voting already took place, but
ultimately would not really solve "incomplete" RFCs as perhaps completing
an RFC might take an extra year or two.


On Tue, Aug 24, 2021 at 4:43 AM Faizan Akram Dar <faizanakram99@gmail.com>
wrote:

> Hi,
>
> I agree with Tobias. Such changes / requests are rare and require a
> judgement call.
>

While I don't disagree that exceptional processes are largely dependent on
judgement calls, I don't think the proposal would largely step on such a
matter. Taking the Nullable Intersection Type as an example, the author
felt that the process was lacking in clarity. Another aspect that can be
evaluated is that a Refinement RFC policy could allow shorter RFC periods
due to it's limited scope, helping both RFC Authors and Release Managers to
work within their deadline.

--00000000000008d04605ca4c696b--