Re: [PHP-DEV] Guidelines for RFC post feature-freeze

This is only part of a thread. view whole thread
  115823
August 25, 2021 17:29 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le mar. 24 août 2021 à 08:09, Pierre Joye php@gmail.com> a écrit :

> 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 which > > 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 the > > 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
  115824
August 25, 2021 17:32 ocramius@gmail.com (Marco Pivetta)
Hey Nicolas,


On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas grekas+php@gmail.com>
wrote:

> I would welcome a new RFC to clarify what is allowed during the feature > freeze. >
See https://en.wikipedia.org/wiki/Freeze_(software_engineering) Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  115825
August 25, 2021 17:34 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le mer. 25 août 2021 à 19:32, Marco Pivetta <ocramius@gmail.com> a écrit :

> Hey Nicolas, > > > On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < > nicolas.grekas+php@gmail.com> wrote: > >> I would welcome a new RFC to clarify what is allowed during the feature >> freeze. >> > > See https://en.wikipedia.org/wiki/Freeze_(software_engineering) >
Thank you Marco, Can you please let me know how that helps?
  115826
August 25, 2021 18:09 derick@php.net (Derick Rethans)
On 25 August 2021 18:34:18 BST, Nicolas Grekas grekas+php@gmail.com> wrote:
>Le mer. 25 août 2021 à 19:32, Marco Pivetta <ocramius@gmail.com> a écrit : ,
> >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < >> nicolas.grekas+php@gmail.com> wrote: >> >>> I would welcome a new RFC to clarify what is allowed during the feature >>> freeze. >>> >> >> See https://en.wikipedia.org/wiki/Freeze_(software_engineering) >> > > >Can you please let me know how that helps?
Maybe you didn't read the post, but generally a feature freeze in software development is some time were no new features are added so a code base can stabilise. This usually happens just before a release. These periods are really important as they allow for 3rd party tools, documentation, etc to be ready when a piece of software is released. On top of that, this period can also be used by users to make sure everything is stable, and that there are no critical bugs. cheers Derick
  115844
August 26, 2021 03:19 pierre.php@gmail.com (Pierre Joye)
Hi,

On Thu, Aug 26, 2021, 1:09 AM Derick Rethans <derick@php.net> wrote:

> On 25 August 2021 18:34:18 BST, Nicolas Grekas < > nicolas.grekas+php@gmail.com> wrote: > >Le mer. 25 août 2021 à 19:32, Marco Pivetta <ocramius@gmail.com> a écrit > : > , > > > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < > >> nicolas.grekas+php@gmail.com> wrote: > >> > >>> I would welcome a new RFC to clarify what is allowed during the feature > >>> freeze. > >>> > >> > >> See https://en.wikipedia.org/wiki/Freeze_(software_engineering) > >> > > > > > >Can you please let me know how that helps? > > Maybe you didn't read the post, but generally a feature freeze in software > development is some time were no new features are added so a code base can > stabilise. This usually happens just before a release. These periods are > really important as they allow for 3rd party tools, documentation, etc to > be ready when a piece of software is released. On top of that, this period > can also be used by users to make sure everything is stable, and that there > are no critical bugs. >
I suppose everyone knows what a freeze is. Also the issue here is not about the PHP features freeze period (RMs do a good job here to announce and update it well on advance). It is about amending RFC for completeness (or whatever other reasons). I can understand a RFC author does not want it for some random extension being added. However I do see challenges when it comes to the very PHP core syntax and languages. As we expected many years ago when we introduced the RFC process, I do see a need to slightly clarify how the core of the PHP language is handled. Not to block any changez but really to make it clear, what we can accept, veto possible (it is now), etc. For the discussion about whether the null intersection was a feature or a refinement, I would suggest just to ignore it. too late too little. best, Pierre
>
  115845
August 26, 2021 04:48 guest271314@gmail.com (guest271314)
Hi.

I read the requirements to ask for a feature. I have been following your
list. Interesting. I just want to do this
https://web.dev/fetch-upload-streaming/,
https://glitch.com/edit/#!/fetch-request-stream.

This works as expected with a Blob or File:

php://input', 'rb');
  $file = fopen('test.txt', 'a');
  stream_copy_to_stream($input, $file);
  $copy = fopen('test.txt', 'rb');
  echo stream_get_contents($copy);
  fclose($input);
  fclose($file);
  fclose($copy);
?>

fetch('index.php', {
  headers: { 'Content-Type': 'text/plain' },
  allowHTTP1ForStreamingUpload: true,
  method: 'post',
  body: new ReadableStream({
    start(c) {
      c.enqueue(new Blob([123]));
      c.close();
    },
  }),
})
..then((r) => r.text())
..then(console.log)
..catch(console.error);

At HTML document:

POST http://localhost:8000/index.php net::ERR_FAILED
TypeError: Failed to fetch

PHP built-in server:

Invalid request (Unexpected EOF)


in PHP. I tried to unsubscribe from your list, got mail error. If you find
the time, can you kindly direct me to where this is possible in PHP, or if
you find the use case a positive addition to PHP, perhaps work towards
implementing it. Kindly unsubscribe me from your mailing list. You folks
are involved. Carry on.

On Wed, Aug 25, 2021 at 8:19 PM Pierre Joye php@gmail.com> wrote:

> Hi, > > On Thu, Aug 26, 2021, 1:09 AM Derick Rethans <derick@php.net> wrote: > > > On 25 August 2021 18:34:18 BST, Nicolas Grekas < > > nicolas.grekas+php@gmail.com> wrote: > > >Le mer. 25 août 2021 à 19:32, Marco Pivetta <ocramius@gmail.com> a > écrit > > : > > , > > > > > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < > > >> nicolas.grekas+php@gmail.com> wrote: > > >> > > >>> I would welcome a new RFC to clarify what is allowed during the > feature > > >>> freeze. > > >>> > > >> > > >> See https://en.wikipedia.org/wiki/Freeze_(software_engineering) > > >> > > > > > > > > >Can you please let me know how that helps? > > > > Maybe you didn't read the post, but generally a feature freeze in > software > > development is some time were no new features are added so a code base > can > > stabilise. This usually happens just before a release. These periods are > > really important as they allow for 3rd party tools, documentation, etc to > > be ready when a piece of software is released. On top of that, this > period > > can also be used by users to make sure everything is stable, and that > there > > are no critical bugs. > > > > > I suppose everyone knows what a freeze is. > > Also the issue here is not about the PHP features freeze period (RMs do a > good job here to announce and update it well on advance). > > It is about amending RFC for completeness (or whatever other reasons). I > can understand a RFC author does not want it for some random extension > being added. However I do see challenges when it comes to the very PHP core > syntax and languages. > > As we expected many years ago when we introduced the RFC process, I do see > a need to slightly clarify how the core of the PHP language is handled. Not > to block any changez but really to make it clear, what we can accept, veto > possible (it is now), etc. > > For the discussion about whether the null intersection was a feature or a > refinement, I would suggest just to ignore it. too late too little. > > best, > Pierre > > > >
  115833
August 25, 2021 20:19 ramsey@php.net (Ben Ramsey)
--nSBXVqLi6FMVgalXbpD5x2j9Qj9ae56xA
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Nicolas Grekas wrote on 8/25/21 12:29:
> I would welcome a new RFC to clarify what is allowed during the feature=
> freeze.=20
As Derick mentioned in another post (by essentially quoting the Wikipedia entry for "Feature freeze"), this period is a well-understood phase of software development. We use this phase for fixing bugs and stabilizing implementations. Changing how a feature works or adding to a feature classifies as new feature development and is not a bugfix or stability improvement. Even the definition proposed for a "Refinement RFC" is describing new feature development (it proposes "changes, amendments, adjustments to the language while refining an unreleased change that has been approved"). A refinement is a new feature. A bugfix is not a refinement.
> 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.)
We announced Beta 1 on 22 July, which is the same date you opened the Nullable Intersection Types RFC. So, according to your own opinion, you opened it too late for re-discussion. I'm not sure what you mean by "re-discussable." Do you mean that you want to challenge a feature that's already been accepted? I think that's fine prior to feature freeze, but afterwards, unless new information reveals significant risk to the release, we shouldn't attempt to reverse or change the decision of the voters.
> WIth the current feature freeze schedule, I realize that there is littl= e 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 happil= y
> use it. I think others would too.
I think this is a good point. Right now, we don't define this period. Since feature freeze starts at the first beta release, this implies that this period is during the alpha releases. Perhaps we should lengthen the alpha phase to provide more time for userland testing. Unfortunately, through my conversations with other userland library maintainers, many don't want to attempt testing until the release candidates are available, so that's a problem in itself. Cheers, Ben --nSBXVqLi6FMVgalXbpD5x2j9Qj9ae56xA--