Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115823
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
In-Reply-To: <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
Date: Wed, 25 Aug 2021 19:29:44 +0200
Message-ID: <CAOWwgpmEpzPURtcASMH_VLNdtb0Qmhg5HEOuRFRZ4x+97KteLw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005218e405ca659929"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000005218e405ca659929
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 24 ao=C3=BBt 2021 =C3=A0 08:09, Pierre Joye <pierre.php@gmail.com> =
a =C3=A9crit :

> Hi Marco,
>
> On Tue, Aug 24, 2021 at 3:49 AM Deleu <deleugyn@gmail.com> wrote:
> >
> > Hello everyone!
> >
> > 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 whi=
ch
> > 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].
> >
> > [1] https://wiki.php.net/rfc/namespaced_names_as_token
> > [2] https://wiki.php.net/rfc/attributes_v2
> >
> > I would like to gather opinion on a potential Policy RFC that would
> define
> > some guidelines for such a process. As Nikita pointed out [3], the
> ability
> > to refine new features is both important for the developer and
> undocumented
> > for the PHP Project.
> >
> > In order to not be empty-handed, I started a gist that can be seen as t=
he
> > starting point for this discussion, available at
> > https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105.
> >
> > Generally speaking, I'm first looking for feedback on whether this is
> > something that deserves attention and an RFC or is it so rare that it's
> > fine to leave it unchanged. If there is interest in moving forward, I
> would
> > then also be interested in suggestions on things that should be
> > included/excluded in the RFC.
>
> 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".
>
> Many additions went through while being incomplete. It was documented
> so in the RFC but it does not make it a good thing. Many of them are
> indeed much needed and related to features (some) PHP users have been
> waiting for. Are they critical enough for the PHP usage to allow them
> in while knowing it is not complete? For almost all recent RFCS
> related to syntax, arguments/return types or properties, I don't think
> it justifies being added while being incomplete. It is not critical
> enough to the larger user base. It makes migration paths harder as
> well.
>
> A library or framework (main users of most of these features) may or
> may not implement the given addition, requiring say 8.1, and yet again
> require 8.2 and redo the implementation to support (hopefully) the
> full features.
>
> This is a path I dislike, I may have a different view on the big
> picture, however I do think we rushed too many of these features too
> early. A vote does not solve this problem given the limited amount of
> votes we can see.
>

Thanks for writing this Pierre, I wholeheartedly agree with this. This was
the fundamental trigger to my RFC: trying to make intersection types closer
to general usefulness *in*my*opinion*! (I don't want to reopen the topic :)
)

I would welcome a new RFC to clarify what is allowed during the feature
freeze. As I wrote in another thread, my opinion is that anything that is
not yet released should be re-discussable until either beta or RC stage, at
least for simple changes (I wouldn't have submitted my RFC if the patch
wasn't trivial from a technical pov.)

WIth the current feature freeze schedule, I realize that there is little to
no room for userland to play with a feature-full binary before it's too
late to give feedback. I experienced this when I was objected that the RFC
was 4 months old already. I can't keep up with testing all RFCs. But if
there is a clear window where such feedback is welcomed, I would happily
use it. I think others would too.

Nicolas

--0000000000005218e405ca659929--