Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Dan. I do appriciate to hear your point of view. This thread is now very off-topic. With respect to Marco and other people that wants to discuss guidelines for the RFCs and the role of RMs, I will not answer you anymore. Feel free to reach out to me privately or in a new thread. // Tobias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Fri, 27 Aug 2021 at 19:11, Tobias Nyholm wrote: > Hey Dan. > > I see that you read what I wrote and intrepid it in the worst possible way. This is also passive aggressive phrasing. You're trying to make me feel bad for pointing out how your phrasing is not conducive to a pleasant productive conversation. > I called it an “obvious mistake” because it was clear to me that we missed > something. 'We' didn't miss it. You might have, but multiple people have explained multiple times that it was a deliberate choice to limit the scope of work for one RFC. If you had written "I consider it a mistake" that leaves room for other people to have a different opinion. But you have kept writing things like "Just because it was intentional, does not make it less of a mistake." which is dismissive of other people's point of view. > I think there are over 1000 people with “voting powers”. I assume > you trust a majority of them to have this “deep enough understanding of PHP > core”. Well. Most of the time people will only vote if they feel they understand the subject being discussed, and have enough confidence that voting a particular way is the right choice. That's quite different from trying to make someone _have_ to say yes or no. But there is at least one RFC that, in my opinion, there were a lot of people who voted who did not fully understand the technical details, or the implications for on-going maintenance: https://wiki.php.net/rfc/jit > If you don’t trust the release managers to manage the release, Ben is right, I didn't say that. I was responding to your sentence which was "what to include and not to include in a release.". > then I suggest you should improve the way we select new release managers. 'Volunteering' other people to do work is also a passive aggressive way of phrasing things. You're the person who is apparently unhappy with the current process that has been used for over a decade. If you want it changed, you do the work to change it. > This is the the extended power I would like the RMs (as a group) to have. That is also volunteering other people for more work. IMO the position of RM is already stressful enough, to the extent that I will never volunteer to be one, as it would cause me to have a nervous breakdown. Making it so that they also have to be arbiters of which post feature freeze RFCs are 'valid' or not would be an extra, and stressful, burden for them to carry. Pierre Joye wrote: > > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md Well, as the mailing rules have been linked, I might as well quote this bit: "Do not top post. Place your answer underneath anyone you wish to quote and remove any previous comment that is not relevant to your post." sincerely Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Sat, Aug 28, 2021, 12:39 AM Dan Ackroyd wrote: > On Tue, 24 Aug 2021 at 20:02, Pierre Joye wrote: > > > > good evening Dan, > > > > First of all, could you please not merge many different mails in one > single reply? Thanks. > > No. This is a mailing list, where conversations get spread over > different forks of threads. > > When a reply is relevant to multiple previous messages, it's better to > combine them so people can see a complete message at once, rather than > expecting people to read through multiple messages in the correct > order, to understand what I'm saying. > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md https://www.php.net/mailing-lists.php please note that nowhere in these rules there is plural being used for the mail's author you are going to reply to. This is also a very common, wide spread, netiquette across almost all MLs I use. So. That's it. Rest is not relevant anymore. There is no point to split hairs any longer. >
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm wrote: > > But I do agree with you. The process would have been way better if they > said “no". Or if they clearly and unanimously said “yes” which would remove > focus on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. > > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. > > // Tobias > I do not believe the reason people felt it was rushed is because of ambiguity from RMs. The reason people felt it was rushed is because: 1. It was a special case of combination types, which voters understood to be a feature targeting 8.2 2. Because it was a feature understood to be targeting 8.2, there was insufficient research into what was technically possible or favorable for general combination types. 3. Because it was a feature understood to be targeting 8.2, it had been specifically excluded from the intersection types RFC. None of those would have been addressed by anything from the RMs, because all of those have to do with the voters' understanding of what the roadmap is and what they had previously voted on. The people who had voted to include intersection types had very specifically been told that they were not nullable, and voted for it anyway, knowing that nullability would come when anticipated support for combination types came. This is my understanding of the situation, in any case. Jordan
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Tobias Nyholm wrote on 8/27/21 13:11: >>> one way of reading this proposal is that we don’t trust the release >>> managers to decide what to include and not to include in a release. >> >> To be clear, I don't trust release managers to decide that. Though >> they are all lovely people, not all of them have a deep enough >> understanding of PHP core to be fully able to evaluate changes. > > If you don’t trust the release managers to manage the release, then I suggest > you should improve the way we select new release managers. I'm not speaking for Dan here, but as one of the release managers, I don't think Dan's statement was intended to mean he doesn't trust the release managers to "manage the release." What he said is that he doesn't trust the release managers to decided what to include and not include in a release. A PHP release manager's job is narrowly defined as: > A release manager's role includes making packaged source code > from the canonical repository available according to their release > schedule.[1] That's pretty much it. That's our job. Our job is NOT to decide what goes into a release. That's the job of the voters. That said, the release schedule (which is completely within the purview of the release managers' jobs) defines dates for each release, including the feature freeze, and the release managers have the authority to change these dates, if necessary. We did not choose the change the dates in this circumstance because there was no need to change them. There were no issues requiring a change to the release schedule. >> One of the hardest things to do in an Open Source project is to say >> 'no' to someone when they are making a request that isn't completely >> unreasonable. IMO, it would have been better if the 8.1 RM managers >> had said no to opening the "Nullable Intersection types" RFC, > > Yes, but it does not mean that you *have to* say no. > But I do agree with you. The process would have been way better if they said > “no". Or if they clearly and unanimously said “yes” which would remove focus > on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. We already have this power, and we exercised this power in this particular situation, but we are also human, and we made some communication mistakes. > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. To be clear, we DO NOT have the power to veto an RFC, and this is not a power the release managers should ever have. Cheers, Ben [1]: https://github.com/php/php-src/blob/master/docs/release-process.md signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Dan. I see that you read what I wrote and intrepid it in the worst possible way. I will try to be more clear and more carefully chose my words in the future. I called it an “obvious mistake” because it was clear to me that we missed something. We are not bad people or worse developers because we made a mistake. We (the community) are also not shielded from making mistakes just because we have a voting process. I understand that other people are not consider it to be a mistake. That is fine. I am wrong to call it “obvious”. >> one way of reading this proposal is that we don’t trust the release managers >> to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes. I think there are over 1000 people with “voting powers”. I assume you trust a majority of them to have this “deep enough understanding of PHP core”. If you don’t trust the release managers to manage the release, then I suggest you should improve the way we select new release managers. > One of the hardest things to do in an Open Source project is to say > 'no' to someone when they are making a request that isn't completely > unreasonable. IMO, it would have been better if the 8.1 RM managers > had said no to opening the "Nullable Intersection types" RFC, Yes, but it does not mean that you *have to* say no. But I do agree with you. The process would have been way better if they said “no". Or if they clearly and unanimously said “yes” which would remove focus on “it feels rushed” and “we can’t because of feature freeze”. This is the the extended power I would like the RMs (as a group) to have. To be clear, Im not suggesting they should veto every RFC. Just changes during feature freeze. Since RMs are experienced open source developers, Im sure they know to ask for help privately whenever they need it. // Tobias > On 27 Aug 2021, at 10:44, Dan Ackroyd wrote: > > Tobias wrote: > >> I know you are not a bad person... >> >> The fact that you unprompted (as far as I can tell) decided to in >> detail specify how RMs should make their decision about an RFC is >> giving me a strong signal that you don’t trust the role of the Release >> Manager. The timing of your RFC is also unfortunate assuming you don’t >> want to imply they are doing a poor job as they just got some criticism >> in a different thread. >> >> I may be wrong and the current and previous release managers feel like >> they really need another policy dictating their work, if so I really >> hope you worked with a few of them while you drafted this RFC. > > If you're going to call people names, you may as well do it openly, > rather than through passive aggressive phrasing like this. > > Also, if you could stop describing decisions that you disagree with as > "obvious mistakes" when the RFC author was pretty clear about the > intention, and the vote passed 30 - 3. > > Quite a few times you're giving the impression that you think other > people are dumb if they can't even see this "obvious mistake". > >> And to state something I hope is obvious: I am not accusing you for trying >> to reduce the role of Release Manager or anything else. > > You are projecting here. > > You're the person who is proposing giving Release Managers new powers > to have special RFCs where "vote should not consider “if it is too > late” or “this is rushed”." > >> To allow the release managers to have this decision power is not a >> “violation of voter rights”, that is just a silly argument. > > It's a change from what we've had before, and blowing off other > people's concerns about putting too much power in the hands of a few > people is condescending. > >> one way of reading this proposal is that we don’t trust the release managers >> to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes. > > Coincidentally, it is explicitly listed that the Release Manager role > does not include deciding what gets shipped - > https://wiki.php.net/rfc/releaseprocess#rms_role > > "RMs Role - But they are not: Decide which features, extension or SAPI > get in a release or not" > > Nicolas Grekas wrote: >> Can you please let me know how that helps? > > It helps point out how obtuse you are being. > > Yeah, everyone gets it, there are quite a few people who commit to > Symfony who don't like that the "Pure intersection types" RFC only > implemented a pure intersection type and didn't allow a union type > with null. > > But having people from that community turn up, call people names, call > things "obvious mistakes" and try to change what feature freeze means > e.g. > >> but what is
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Tobias wrote: > I know you are not a bad person... > > The fact that you unprompted (as far as I can tell) decided to in > detail specify how RMs should make their decision about an RFC is > giving me a strong signal that you don’t trust the role of the Release > Manager. The timing of your RFC is also unfortunate assuming you don’t > want to imply they are doing a poor job as they just got some criticism > in a different thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really > hope you worked with a few of them while you drafted this RFC. If you're going to call people names, you may as well do it openly, rather than through passive aggressive phrasing like this. Also, if you could stop describing decisions that you disagree with as "obvious mistakes" when the RFC author was pretty clear about the intention, and the vote passed 30 - 3. Quite a few times you're giving the impression that you think other people are dumb if they can't even see this "obvious mistake". > And to state something I hope is obvious: I am not accusing you for trying to > reduce the role of Release Manager or anything else. You are projecting here. You're the person who is proposing giving Release Managers new powers to have special RFCs where "vote should not consider “if it is too late” or “this is rushed”." > To allow the release managers to have this decision power is not a > “violation of voter rights”, that is just a silly argument. It's a change from what we've had before, and blowing off other people's concerns about putting too much power in the hands of a few people is condescending. > one way of reading this proposal is that we don’t trust the release managers > to decide what to include and not to include in a release. To be clear, I don't trust release managers to decide that. Though they are all lovely people, not all of them have a deep enough understanding of PHP core to be fully able to evaluate changes. Coincidentally, it is explicitly listed that the Release Manager role does not include deciding what gets shipped - https://wiki.php.net/rfc/releaseprocess#rms_role "RMs Role - But they are not: Decide which features, extension or SAPI get in a release or not" Nicolas Grekas wrote: > Can you please let me know how that helps? It helps point out how obtuse you are being. Yeah, everyone gets it, there are quite a few people who commit to Symfony who don't like that the "Pure intersection types" RFC only implemented a pure intersection type and didn't allow a union type with null. But having people from that community turn up, call people names, call things "obvious mistakes" and try to change what feature freeze means e.g. > but what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > anything that is not yet released should be re-discussable until either > beta or RC stage. One of the hardest things to do in an Open Source project is to say 'no' to someone when they are making a request that isn't completely unreasonable. IMO, it would have been better if the 8.1 RM managers had said no to opening the "Nullable Intersection types" RFC, but I'm also pretty sure they expected you to behave better and not to throw mud around what processes the PHP does or should follow. If you want people who contribute to PHP core to ship 'more complete' features, how about getting Symfony the company (or any other company) to sponsor some of them: https://phpopendocs.com/sponsoring/internals cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Tue, 24 Aug 2021 at 20:02, Pierre Joye wrote: > > good evening Dan, > > First of all, could you please not merge many different mails in one single > reply? Thanks. No. This is a mailing list, where conversations get spread over different forks of threads. When a reply is relevant to multiple previous messages, it's better to combine them so people can see a complete message at once, rather than expecting people to read through multiple messages in the correct order, to understand what I'm saying. > PHP is not at a stage where what > is missing are easy additions like simple scalar return types. First, "simple scalar return types" was not an RFC, that is at least two RFCs or three: Return Type Declarations - https://wiki.php.net/rfc/return_types - 2014-03-20 Nullable Types - https://wiki.php.net/rfc/nullable_types - 2014-04-10 Scalar Type Declarations - https://wiki.php.net/rfc/scalar_type_hints_v5 - 2015-02-18 To me, this is a good example of how breaking large chunks of work is an effective strategy. Second, you are either completely forgetting or just denigrating the amount of work that was involved in getting scalar types passed. It was a shitshow of a discussion that took a huge amount of effort to get passed. Coming up with the technical details and implementing an RFC are only part of the process, and are the fun bit. But then after that any RFC author has to persuade the rest of PHP internals that it's a good idea. I talk to some of the people who do RFCs and one of the common things I hear is that listening to internals feedback is a hugely stressful and difficult thing to do. This may be different to when you last passed an RFC, at least in part because there are now relatively more people who don't commit to PHP-src frequently (or at all) taking part in discussions, and so RFC authors find it really hard to figure out which feedback should be listened to, and which feedback is less relevant. Although listening to user feedback can be useful, there is a lack of detailed technical feedback and help in implementing RFCs. > As the recent discussions show, it needs more time to design, > plan and implement the desired additions. Just saying people should work harder doesn't help. I'll agree that the project would be in a better place if there were more people making technical contributions but PHP is worked on by volunteers. But just having people show up after RFCs have been passed, and say "the work done isn't good enough" is completely disrespectful to the people who have been maintaining and improving PHP. I don't think a more difficult process is what the PHP project needs. Instead it needs more people able to, and willing to work on the code. One thing that might help with that is getting more sponsoring of people who have done work. I've made a list of RFC authors here: https://phpopendocs.com/sponsoring/internals sincerely Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hello, One question I have (as I always do) regarding nullable intersection types, (which is a forbidden topic and I know I shouldn't bring it up). I'd love to know how `Consistency` plays a role in new RFCs. Are we striving for consistency? Is it a value here? Or simply it is a side effect? We sorta have nullability everywhere, `function/method parameters`, `return types`, properties. (please let me know if I am wrong; I'd love to know :D) Until comes an RFC which intentionally and reasonably drops an area for a later time but in doing so brings in a new feature that is not consistent with other parts of the software. Now we don't have the consistency which we used to have. I know it is supposed to be temporary but it doesn't make it less inconsistent! Then came a new RFC which is addressing an issue, which from a different point of view it could be regarded as fixing this inconsistency. Now, should we discard this issue and let the inconsistency creep into the system? What approaches are we employing for tackling these sorts of issues? Do we even care about that? :/ >From yet a different point of view, for users unaware of this inconsistency, it could easily waste their precious time. (Maybe seconds :D ; it doesn't make it less precious) PS: I'm not conveying anything here (:D). I am simply a curious person. I also know what feature freeze means and I'm all for it. :) Regards,
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
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:
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 wrote:
> Hi,
>
> On Thu, Aug 26, 2021, 1:09 AM Derick Rethans wrote:
>
> > On 25 August 2021 18:34:18 BST, Nicolas Grekas <
> > nicolas.grekas+...@gmail.com> wrote:
> > >Le mer. 25 août 2021 à 19:32, Marco Pivetta a
> écrit
> > :
> > ,
> > >
> > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas <
> > >> nicolas.grekas+...@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
>
> >
>
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hi, On Thu, Aug 26, 2021, 1:09 AM Derick Rethans wrote: > On 25 August 2021 18:34:18 BST, Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >Le mer. 25 août 2021 à 19:32, Marco Pivetta a écrit > : > , > > > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < > >> nicolas.grekas+...@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 >
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Wed, Aug 25, 2021 at 10:25 PM Ben Ramsey 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 to > 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. -- Marco Aurélio Deleu
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Nicolas Grekas wrote on 8/25/21 12:29: > I would welcome a new RFC to clarify what is allowed during the feature > freeze. 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 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. 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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Deleu wrote on 8/25/21 14:35: > On Wed, Aug 25, 2021 at 8:52 PM Ben Ramsey wrote: >> I would be in favor of an "informational" RFC rather than a "policy" >> RFC. An informational RFC can define terms, such as "refinement RFC" and >> "feature freeze," without burdening the project with more policy overhead. > > Do we have the concept of an informal RFC? As far as I could see there are > language changes targeting a specific version and policy and processes [1]. > I could not find another type of RFC to be proposed. I meant "informational" not "informal." I don't know that we have that concept in any of the PHP RFCs, but I know that IETF RFCs, Python PEPs, and others have the concept of informational documents that do not prescribe process, policy, or recommendations. Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Wed, Aug 25, 2021 at 9:00 PM Ben Ramsey wrote: > Derick Rethans wrote on 8/24/21 12:35: > > On Mon, 23 Aug 2021, Deleu wrote: > > > >> 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. > > > > 4. A Refinement RFC MAY be proposed with a schedule for ending it's vote > > after feature freeze if at least one Release Manager approves it. > > > > IMO, they should have consensus. > > Agreed. I wasn't aware of the Nullable Intersection Types RFC myself > until this week, and that's on me. I would probably have disagreed with > allowing it. > > Cheers, > Ben > > This was the primary reason why I wrote item 4 like that. I feel that it would be unreasonable to expect every release manager to be aware of every detail at all times. They are volunteers that may need some time off, be on holiday or simply unavailable. In the absence of one of the Release Managers, another one can grant the right for a Refinement RFC. Such a decision would be partially temporary because once all Release Managers are aware of the events they would then be able to make an unanimous decision of rescinding the grant if that's what's best for the project. A Refinement RFC Author has to be willing to take such a risk. On Wed, Aug 25, 2021 at 8:52 PM Ben Ramsey wrote: > > I would be in favor of an "informational" RFC rather than a "policy" > RFC. An informational RFC can define terms, such as "refinement RFC" and > "feature freeze," without burdening the project with more policy overhead. > > Cheers, > Ben > Do we have the concept of an informal RFC? As far as I could see there are language changes targeting a specific version and policy and processes [1]. I could not find another type of RFC to be proposed. [1] https://wiki.php.net/rfc --- On Wed, Aug 25, 2021 at 8:16 PM Derick Rethans wrote: > > >Can you please clarify what you want to express here? Your insistence in > >repeating that statement makes me read this as: "the nullable > intersections > >RFC was not legal". > > You're wanting to add a new feature during feature freeze, so yes, I > wouldn't have allowed it. > > > If that's the case, I find that deeply disturbing, > >because I need to be allowed to discuss not-yet-released features during > >the freeze period. > > Yes, suggesting tweaks to existing features is fine, up to a certain > point. Introducing new ones is not. > > > Whether an RFC should be considered as a new feature > >should be the end of the discussion, not the abruptly-closing start. The > >reason is that there is no precise definition of what "a feature" means. > > The RFC was "pure intersection types", with a scope decided by its author. > That RFC says no Union types. > > >Maybe it's obvious for you in this case, but others shouldn't be denied > the > >right to discuss the topic. > > Discuss whatever you want, but that doesn't mean that a new feature RFC > should be allowed during a feature freeze. > > >I think that we can reach a common agreement by working on the definition > >of what we mean by "Refinement RFC". > > > >Marco's gist defines them as "An RFC proposing changes, amendments, > >adjustments to the language while refining an unreleased change that has > >been approved." I'm sure we can improve it, but I mostly agree with this > >statement. My RFC falls under this definition, > > I disagree that it does. Union intersection types is something that the > pure intersection types RFC ruled out. > > Cheers > Derick > > I believe this discussion goes to show that Release Managers judgement call is the key aspect of these events and will continue to be. Ultimately it will depend on who the release manager is and how the idea is proposed. This RFC would not change this, but explicitly state the steps and the possibilities. If an RFC author cannot convince Release Managers that their proposal falls under Refinement RFC, they will be denied the chance to make their case after feature freeze, as they already are. On the other hand, even if a Release Manager strongly objects to a proposal, they still have the ability to put it to a vote if they believe it to be a refinement proposal. -- Marco Aurélio Deleu
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Derick Rethans wrote on 8/24/21 12:35: > On Mon, 23 Aug 2021, Deleu wrote: > >> 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. > > 4. A Refinement RFC MAY be proposed with a schedule for ending it's vote > after feature freeze if at least one Release Manager approves it. > > IMO, they should have consensus. Agreed. I wasn't aware of the Nullable Intersection Types RFC myself until this week, and that's on me. I would probably have disagreed with allowing it. Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Sara Golemon wrote on 8/24/21 14:29: > 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". Agreed. We already have a policy for this, and the RMs are empowered to make these decisions now. This RFC doesn't define anything new. > 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. I would be in favor of an "informational" RFC rather than a "policy" RFC. An informational RFC can define terms, such as "refinement RFC" and "feature freeze," without burdening the project with more policy overhead. Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On 25 August 2021 17:58:55 BST, Nicolas Grekas wrote: >Le mar. 24 août 2021 à 21:09, Derick Rethans a écrit : > >> On 24 August 2021 19:53:57 BST, Deleu wrote: >> >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote: >> > >> >> On Mon, 23 Aug 2021, Deleu wrote: >> >> >> >> > 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]. >> >> >> >> I find this comparison disingenuous. >> >> >> > >> >I want to state that I had no intention to compare the RFCs or even bring >> >their merits into discussion. What I intended to show is that we have 8.0 >> >which had an RFC that would classify as Refinement RFC and 8.1 again >> having >> >another RFC that also classifies under the same category. >> >> That's where I disagree already. The nullable intersections RFC isn't a >> refinement, it's a new feature. > >Can you please clarify what you want to express here? Your insistence in >repeating that statement makes me read this as: "the nullable intersections >RFC was not legal". You're wanting to add a new feature during feature freeze, so yes, I wouldn't have allowed it. > If that's the case, I find that deeply disturbing, >because I need to be allowed to discuss not-yet-released features during >the freeze period. Yes, suggesting tweaks to existing features is fine, up to a certain point. Introducing new ones is not. > Whether an RFC should be considered as a new feature >should be the end of the discussion, not the abruptly-closing start. The >reason is that there is no precise definition of what "a feature" means. The RFC was "pure intersection types", with a scope decided by its author. That RFC says no Union types. >Maybe it's obvious for you in this case, but others shouldn't be denied the >right to discuss the topic. Discuss whatever you want, but that doesn't mean that a new feature RFC should be allowed during a feature freeze. >I think that we can reach a common agreement by working on the definition >of what we mean by "Refinement RFC". > >Marco's gist defines them as "An RFC proposing changes, amendments, >adjustments to the language while refining an unreleased change that has >been approved." I'm sure we can improve it, but I mostly agree with this >statement. My RFC falls under this definition, I disagree that it does. Union intersection types is something that the pure intersection types RFC ruled out. > and that should be enough to >end the debate around whether any particular post-feat-freeze RFCs are >legal. I think we should focus our efforts on improving this definition, >and move forward. This is all moot, because that RFC hasn't been passed. I also don't think it's necessary. If you want to disregard the concept of a feature freeze, that's fine too. But not in the PHP project. Cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On 25 August 2021 18:34:18 BST, Nicolas Grekas wrote: >Le mer. 25 août 2021 à 19:32, Marco Pivetta a écrit : , > >> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < >> nicolas.grekas+...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Le mer. 25 août 2021 à 19:32, Marco Pivetta a écrit : > Hey Nicolas, > > > On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas < > nicolas.grekas+...@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?
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Nicolas, On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas 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/
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Le mar. 24 août 2021 à 08:09, Pierre Joye a écrit : > Hi Marco, > > On Tue, Aug 24, 2021 at 3:49 AM Deleu 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
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Le mar. 24 août 2021 à 21:09, Derick Rethans a écrit : > On 24 August 2021 19:53:57 BST, Deleu wrote: > >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote: > > > >> On Mon, 23 Aug 2021, Deleu wrote: > >> > >> > 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]. > >> > >> I find this comparison disingenuous. > >> > > > >I want to state that I had no intention to compare the RFCs or even bring > >their merits into discussion. What I intended to show is that we have 8.0 > >which had an RFC that would classify as Refinement RFC and 8.1 again > having > >another RFC that also classifies under the same category. > > That's where I disagree already. The nullable intersections RFC isn't a > refinement, it's a new feature. > Hello Derick, Can you please clarify what you want to express here? Your insistence in repeating that statement makes me read this as: "the nullable intersections RFC was not legal". If that's the case, I find that deeply disturbing, because I need to be allowed to discuss not-yet-released features during the freeze period. Whether an RFC should be considered as a new feature should be the end of the discussion, not the abruptly-closing start. The reason is that there is no precise definition of what "a feature" means. Maybe it's obvious for you in this case, but others shouldn't be denied the right to discuss the topic. I think that we can reach a common agreement by working on the definition of what we mean by "Refinement RFC". Marco's gist defines them as "An RFC proposing changes, amendments, adjustments to the language while refining an unreleased change that has been approved." I'm sure we can improve it, but I mostly agree with this statement. My RFC falls under this definition, and that should be enough to end the debate around whether any particular post-feat-freeze RFCs are legal. I think we should focus our efforts on improving this definition, and move forward. Nicolas
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Tue, Aug 24, 2021 at 10:15 PM Tobias Nyholm wrote: > Hey Marco. > > The fact that you unprompted (as far as I can tell) decided to in detail > specify how RMs should make their decision about an RFC is giving me a > strong signal that you don’t trust the role of the Release Manager. The > timing of your RFC is also unfortunate assuming you don’t want to imply > they are doing a poor job as they just got some criticism in a different > thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really hope > you worked with a few of them while you drafted this RFC. > > > // Tobias I have updated the gist to include a Motivation section that attempts to shed a bit more light into what the general idea is. If there is anything in the text of the RFC that validates your perception to the RFC, I would be interested in changing that. As for your perception, I would like to make an attempt to clarify my perspective in the hopes of easing some of these concerns. Timing: I feel like proposing a policy change when it isn't clear why such a proposal is being made is actually worse as it is not clear why such a proposal would be made. I believe timing works in favour of the RFC because people may be more receptive to perceiving that amending the guidelines could have made recent events smoother for people involved. Implying a poor job from Release Managers: As I stated on the Nullable Intersection thread, I don't feel like there was any misconduct or poor handling of the process. In fact, the text I drafted for this RFC simply reinforced everything that was already done: RMs can grant permission for a Refinement RFC and can rescind it. Other release managers would be able to see stated on the RFC that a grant was given. Dictating Release Managers work: The text does not attempt to do that either. It just explicitly empowers Release Managers and instructs RFC Authors how to present a Refinement RFC. Working with Release Managers: I'm a novice in the PHP Project and I don't feel comfortable bothering anybody personally. This thread doesn't even represent the official RFC discussion, it just follows the item 1) of How to Propose a RFC [1]: "Email internals@lists.php.net to measure reaction to your intended proposal." As such, I feel like I'm properly following the guidelines on how to propose an RFC by measuring the reaction of internals about my proposal. Unprompted: As I sadly failed to link on the first email, Nikita has made a comment about whether the process should be a bit more flexible when trying to implement approved RFCs [2]. I saw an opportunity to pick up the work on that and I just did. Part of my motivation is to empower core developers to bring Refinement RFCs whenever they're struggling to land an implementation that suddenly presents challenges that were hidden such as how the Attribute syntax was ambiguous after it had been approved. If I failed to address any of your concerns, I'm happy to try again and I want to reinforce that if you can link any of these concerns you raised to the text of the RFC, I really want to change the text. As an author of a Policy RFC, I want to be absolutely sure that nobody in the future would read the text and feel like the policy is dictating how Release Managers should work. [1] https://wiki.php.net/rfc/howto [2] https://externals.io/message/115700#115753 On Tue, Aug 24, 2021 at 9:30 PM Sara Golemon wrote: > TL;DR - This RFC sounds like a great idea, assuming appropriately scoped. > > -Sara > That's wonderful to read! I'm looking forward to refining the scope as necessary. One question I have for experienced release managers is whether clause 11 is good/bad and whether it should mention a specific number of days or leave it open for judgement calls. -- Marco Aurélio Deleu
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Marco. I know you are not a bad person and Im sure your intention is to bring more clarity and to add something that is helpful. And to state something I hope is obvious: I am not accusing you for trying to reduce the role of Release Manager or anything else. > I'm interested in understanding how the proposal gives this impression The fact that you unprompted (as far as I can tell) decided to in detail specify how RMs should make their decision about an RFC is giving me a strong signal that you don’t trust the role of the Release Manager. The timing of your RFC is also unfortunate assuming you don’t want to imply they are doing a poor job as they just got some criticism in a different thread. I may be wrong and the current and previous release managers feel like they really need another policy dictating their work, if so I really hope you worked with a few of them while you drafted this RFC. // Tobias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Derick, On Tue, Aug 24, 2021 at 9:09 PM Derick Rethans wrote: > That's where I disagree already. The nullable intersections RFC isn't a > refinement, it's a new feature. > And if I had voting powers, that would be exactly my reasoning for voting no: "Not a Refinement RFC". However, whether a Refinement RFC can be proposed or not is up to the Release Manager of the targeting version, which is something that is included in the RFC to formalize what already has precedence. - Tobias, On Tue, Aug 24, 2021, 21:00 Tobias Nyholm wrote: > > The issue I have with adding more guidelines for RFCs “post feature > freeze” is that it removes decision power from the release managers. Ie, > one way of reading this proposal is that we don’t trust the release > managers to decide what to include and not to include in a release. I'm interested in understanding how the proposal gives this impression because others may end up in a similar conclusion and that is far from the intention. Is there a specific part of the text that makes it look like release managers are being stripped of any power? In my perspective, the only way of reading this RFC is: - RFC Authors: don't be afraid of attempting a last-minute change. Just talk to the Release Managers first as it will affect their work. - Release Managers: if a code change looks like it needs an RFC and it will clash with feature freeze, you have the power to provide a speedy RFC by allowing a Refinement RFC. - Voters: When voting on a Refinement RFC, be aware that it may move slightly faster due to time sensitivity and judge for yourself the merits of the proposal. > To allow the release managers to have this decision power is not a > “violation of voter rights”, that is just a silly argument. > Well, thank you? > Maybe we should hear what the current and previous release managers think? > Do they feel like they need more policies around their work? > > // Tobias Gabriel Caruso, release manager of 8.0 has shown his support on this discussion in the first reply of this thread. -- Marco Aurélio Deleu
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm wrote: > > Situations like this often requires a judgement call rather than something > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a “feature freeze”. If the release managers agree that a > change can be added, then the discussion and the vote should not consider > “if it is too late” or “this is rushed”. 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
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On 24 August 2021 19:53:57 BST, Deleu wrote: >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote: > >> On Mon, 23 Aug 2021, Deleu wrote: >> >> > 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]. >> >> I find this comparison disingenuous. >> > >I want to state that I had no intention to compare the RFCs or even bring >their merits into discussion. What I intended to show is that we have 8.0 >which had an RFC that would classify as Refinement RFC and 8.1 again having >another RFC that also classifies under the same category. That's where I disagree already. The nullable intersections RFC isn't a refinement, it's a new feature. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
good evening Dan, First of all, could you please not merge many different mails in one single reply? Thanks. On Wed, Aug 25, 2021, 1:43 AM Dan Ackroyd wrote: > Pierre Joye wrote: > > Many additions went through while being incomplete. > > > For almost all recent RFCS > > related to syntax, arguments/return types or properties, I don't think > > it justifies being added while being incomplete. > > I think you are remembering how changes were made to PHP through rose > tinted glasses. > Not really, or actually not at all. Quite the opposite. Pretty much all of the improvements to PHP's type system were > 'incomplete' but they were still huge chunks of work, and some of them > only just got accepted. This implies that this statement is more accurate than the one in my reply. Suggesting that (other) people need to do more work to satisfy the > level of quality you want in an RFC is a good way of stopping any > major progress from being achieved. > I think there is a misunderstanding here. PHP is not at a stage where what is missing are easy additions like simple scalar return types. As the recent discussions show, it needs more time to design, plan and implement the desired additions. This is why so many languages having reached this level of maturity are extremely prudent when it comes to very long term syntax or features additions. Seeing as a lot of RFCs that improve PHP's type system seem to be the > last RFC before someone decides to not bother contributing any more, I > strongly suggest not trying to make it more difficult to get > improvements made. > I understand your concerns and similar concerns have been brought when we introduced, you guess it, the RFC process. What I am talking about here is to have more clarity and stability how such critical additions are approved, or not. Critical not because of the needs but the permanent state of such additions. And more importantly, how they are designed to begin with. This is rarely a short journey nor a one person show. It is hard to have a diverse group with enough time, knowledge and motivation to work on such ungrateful tasks (but challenging). Such events create exactly what your comment is saying. best, Pierre
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
> Tobias Nyholm wrote: >> then the discussion and the vote should not consider “if it is too late” >> or “this is rushed”. > > This is a really bad idea. Previously (but not recently), some of the > more heated RFC discussions moved from being about the RFC to being > about what are "right" and "wrong" reasons for voting. > > That type of discussion very quickly descends into either name > calling, or people just refusing to take part in discussions. > > If nothing else, how would you 'prove' that someone has voted for the > 'wrong reason', and so needs to have their vote discounted? The issue I have with adding more guidelines for RFCs “post feature freeze” is that it removes decision power from the release managers. Ie, one way of reading this proposal is that we don’t trust the release managers to decide what to include and not to include in a release. To allow the release managers to have this decision power is not a “violation of voter rights”, that is just a silly argument. > 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. Maybe we should hear what the current and previous release managers think? Do they feel like they need more policies around their work? // Tobias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote: > On Mon, 23 Aug 2021, Deleu wrote: > > > 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]. > > I find this comparison disingenuous. > I want to state that I had no intention to compare the RFCs or even bring their merits into discussion. What I intended to show is that we have 8.0 which had an RFC that would classify as Refinement RFC and 8.1 again having another RFC that also classifies under the same category. Their merits are left for their own discussion and their own voting. 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. >
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Pierre Joye wrote: > Many additions went through while being incomplete. > ... > For almost all recent RFCS > related to syntax, arguments/return types or properties, I don't think > it justifies being added while being incomplete. I think you are remembering how changes were made to PHP through rose tinted glasses. Pretty much all of the improvements to PHP's type system were 'incomplete' but they were still huge chunks of work, and some of them only just got accepted. Suggesting that (other) people need to do more work to satisfy the level of quality you want in an RFC is a good way of stopping any major progress from being achieved. Seeing as a lot of RFCs that improve PHP's type system seem to be the last RFC before someone decides to not bother contributing any more, I strongly suggest not trying to make it more difficult to get improvements made. Pierre Joye wrote: > 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 > > What is one more year then? :) If a library thinks a feature is 'incomplete' they can hold off using it, while other people who think it's useful enough can use it earlier. After all, what is one more year then? Pierre Joye wrote: > I don't think we are not able to understand complex RFCs. The intersection types RFC was pretty clear that it didn't support union types. This limitation could have been discussed as part of the RFC discussion, and George would have explained his choice, namely that implementing the RFC was going to be difficult and so he wanted to limit the scope of the RFC*. The fact that this limitation in scope apparently wasn't understood by some people who apparently have strong feelings about it, suggests that people don't always understand what is being discussed or voted on. Tobias Nyholm wrote: > then the discussion and the vote should not consider “if it is too late” > or “this is rushed”. This is a really bad idea. Previously (but not recently), some of the more heated RFC discussions moved from being about the RFC to being about what are "right" and "wrong" reasons for voting. That type of discussion very quickly descends into either name calling, or people just refusing to take part in discussions. If nothing else, how would you 'prove' that someone has voted for the 'wrong reason', and so needs to have their vote discounted? cheers Dan Ack * To be clear, the implementation was very difficult, and George spent a huge amount of time on it. I suggest reviewing the implementation if you aren't familiar with it: https://github.com/php/php-src/commit/069a9fa5e4478c7044cb6432258cfe207d10a202 and definitely before saying that leaving out union types was an 'oversight'. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, 23 Aug 2021, Deleu wrote: > 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. 4. A Refinement RFC MAY be proposed with a schedule for ending it's vote after feature freeze if at least one Release Manager approves it. IMO, they should have consensus. 7. A Refinement RFC MAY have a shorter discussion period, respecting a minimum of 10 days, when it's voting ends after feature freeze. 8. A Refinement RFC MAY have a shorter voting period, respecting a minimum of 10 days, when it's voting ends after feature freeze. Reducing them from 14 to 10 days, seems to make little sense to me. There is no need for a reduced time-table, because of: 11. Release Managers MAY delay RC1 for XX days at their own discretion. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, 23 Aug 2021, Deleu wrote: > 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]. I find this comparison disingenuous. The changes to the Attribute Syntax wasn't a new feature, and started well before feature freeze. and only just missed it, and some of that time wasted was arguably due to not being able to count. The RFC on nullable intersections is a NEW feature, and was started a week after feature freeze had already happened. It was *not* a mistake as the feature was specifically introduced as "pure intersection types", as outlined in the RFC, and re-articulated by the author in an interview (https://phpinternals.news/88#transcript) cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
> > Situations like this often requires a judgement call rather than something > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a “feature freeze”. If the release managers agree that a > change can be added, then the discussion and the vote should not consider > “if it is too late” or “this is rushed”. 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 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 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.
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hi Jordan, On Tue, Aug 24, 2021 at 4:55 PM Jordan LeDoux wrote: > 1. Are too large or complex for voters to make an informed decision about. This is the real problem. Also you are correct on the cause (complexity of a topic), I don't think we are not able to understand complex RFCs. > 2. Include too many aspects which are controversial or which have strongly > opposed viewpoints within the RFC voters. Incomplete implementation of a language construct is an order of magnitude worse than having to wait a bit longer. > RFCs which do either of these two things cannot pass, therefore all RFCs > which pass do neither. Together with others I wrote the RFC RFC along with a few required after this. I fully grasp how hard it can be at times. However language constructs are not some random extensions we can drop, replace etc. They are basically there forever. And forever in my case is as long as PHP exists. What is one more year then? :) > and new language features. Which should be clearly complete to begin with, as much as possible. A hard to find agreement is not a good enough reason to push a new incomplete language feature, in my book. This is my only point. > These are not bad things to value, and I don't see how you can expect RFC > authors to avoid proposing features which some may see as incomplete. My > operator overload RFC is something I've already put at least 100 hours into, > it's trimmed down to a very limited set of operators with restrictions on > certain implementations, I still have many more hours of work left on the > implementation in order to make the necessary changes to opcodes for it, and > it still will likely be something which there is significant resistance to. I > might put in excess of 300-400 hours of work into this RFC only for it to be > rejected because of differences of opinion on the feature. You most likely will, and we are all grateful for that. It also shows that such RFCs are not about a single individual. Language features are better designed, proposed or implemented by a group of persons. That's the tricky part but it may help a lot. > > I would be very disappointed if I was able to successfully convince voters of > the value of my contribution, address the concerns that were presented and > find good compromises, and then be told that my work was faulty and > incomplete because it only allows operator overload for objects instead of > globally or doesn't allow overloading of the null coalesce operator, for > instance. I cannot say anything about it as I did not go through it deeply. However, yes, I would rather vote no on operator overloading not being fully documented in the RFC. I could imagine not every single case could go in the 1st round. While operators overloading add enough complexity already without having to think about where it will work and where not, as an end user. But the roadmap must then be clear, implementation etc. The idea of saying "let see later" is not a good way to accept language changes. Best, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, Aug 23, 2021 at 11:09 PM Pierre Joye wrote: > > 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. > I just wanted to note that while this may be true, it's largely because RFC authors cannot reasonably create and pass RFCs which: 1. Are too large or complex for voters to make an informed decision about. 2. Include too many aspects which are controversial or which have strongly opposed viewpoints within the RFC voters. RFCs which do either of these two things cannot pass, therefore all RFCs which pass do neither. This will always result in RFCs which some people view as "incomplete". It's not because the RFC authors, or even the voters, forgot or "overlooked" something necessarily. It's simply a product of what the PHP voters value. Voters value backwards compatibility; voters value a strong use-case justification for a new feature; voters value consistency between existing language features and new language features. These are not bad things to value, and I don't see how you can expect RFC authors to avoid proposing features which some may see as incomplete. My operator overload RFC is something I've already put at least 100 hours into, it's trimmed down to a very limited set of operators with restrictions on certain implementations, I still have many more hours of work left on the implementation in order to make the necessary changes to opcodes for it, and it still will likely be something which there is significant resistance to. I might put in excess of 300-400 hours of work into this RFC only for it to be rejected because of differences of opinion on the feature. I would be very disappointed if I was able to successfully convince voters of the value of my contribution, address the concerns that were presented and find good compromises, and then be told that my work was faulty and incomplete because it only allows operator overload for objects instead of globally or doesn't allow overloading of the null coalesce operator, for instance. As long as RFC authors must lobby voters to get a feature included, there are features which will be cut in the interest of time, compromise, complexity, and comprehension. I don't see how you avoid that without abandoning the idea of voting altogether, which is something I'm sure we all find value in. Jordan
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hi Marco, On Tue, Aug 24, 2021 at 3:49 AM Deleu 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. Best, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Tue, 24 Aug 2021, 4:27 am Tobias Nyholm, wrote: > Thank you. > I appriciate you bring up this issue. > > Situations like this often requires a judgement call rather than something > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a “feature freeze”. If the release managers agree that a > change can be added, then the discussion and the vote should not consider > “if it is too late” or “this is rushed”. I think we can trust the release > managers to make the correct desiccation without an extra policy. > > // Tobias > > > On 23 Aug 2021, at 13:48, Deleu 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. > > > > Marco Aurélio Deleu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php Hi, I agree with Tobias. Such changes / requests are rare and require a judgement call. PS: Sorry if my email was posted twice, I replied via a different email which is not subscribed to internals list, so wasn't sure.
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Thank you. I appriciate you bring up this issue. Situations like this often requires a judgement call rather than something that could be defined as a policy. I suggest the release managers always should be in agreement before a RFC is created during a “feature freeze”. If the release managers agree that a change can be added, then the discussion and the vote should not consider “if it is too late” or “this is rushed”. I think we can trust the release managers to make the correct desiccation without an extra policy. // Tobias > On 23 Aug 2021, at 13:48, Deleu 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. > > Marco Aurélio Deleu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, 23 Aug 2021, 23:07 Gabriel Caruso, wrote: > On Mon, 23 Aug 2021, 22:49 Deleu, 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. >> >> Marco Aurélio Deleu > > >> >> Thank you for being this one up, and yes: we should be a little bit more >> strict with stuff coming in, post feature freeze period! > > Bringing*, writing is difficult. > In PHP 8.0, Sara and I had the same problem :( >
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Mon, 23 Aug 2021, 22:49 Deleu, 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. > > Marco Aurélio Deleu > > Thank you for being this one up, and yes: we should be a little bit more > strict with stuff coming in, post feature freeze period! In PHP 8.0, Sara and I had the same problem :(
[PHP-DEV] Guidelines for RFC post feature-freeze
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. Marco Aurélio Deleu
