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
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_v2I 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 :(
On Mon, 23 Aug 2021, 23:07 Gabriel Caruso, carusogabriel34@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_v2I 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 :(
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
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_v2I 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.
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
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_v2I 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
--
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.
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.
Hi Marco,
It is a very good text, thank you!
It is also much needed, generally speaking. What I would add is about
what is allowed to begin with. I would rather restrict to fixes only.The other issue, which is the one Nicolas suffered from, incomplete
addition to begin with. Incomplete in the sense of, "We add feature A,
but behaviors A1 and A2 are not supported and can be done later".Best,
Pierre
@pierrejoye | http://www.libgd.org
I believe that the concern you raise here would be categorized as outside
the scope of what I intend to propose. The RFC process is in place to
handle such cases. It may or may not need improvement, but the bottom line
is that if enough voters agree with an RFC, even if everyone agrees that it
is "incomplete" it's still an approved change for the language. A
Refinement RFC policy would extend the time available to deal with
implementation consequences found after the voting already took place, but
ultimately would not really solve "incomplete" RFCs as perhaps completing
an RFC might take an extra year or two.
On Tue, Aug 24, 2021 at 4:43 AM Faizan Akram Dar faizanakram99@gmail.com
wrote:
Hi,
I agree with Tobias. Such changes / requests are rare and require a
judgement call.
While I don't disagree that exceptional processes are largely dependent on
judgement calls, I don't think the proposal would largely step on such a
matter. Taking the Nullable Intersection Type as an example, the author
felt that the process was lacking in clarity. Another aspect that can be
evaluated is that a Refinement RFC policy could allow shorter RFC periods
due to it's limited scope, helping both RFC Authors and Release Managers to
work within their deadline.
On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:
Situations like this often requires a judgement call rather than 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
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
Hi Marco,
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_v2I 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
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:
- Are too large or complex for voters to make an informed decision about.
- 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
Hi Jordan,
- 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.
- 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
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'.
good evening Dan,
First of all, could you please not merge many different mails in one
single reply? Thanks.
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
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
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.
Le mar. 24 août 2021 à 08:09, Pierre Joye pierre.php@gmail.com a écrit :
Hi Marco,
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_v2I 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 inmyopinion! (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
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)
Greets,
Marco Pivetta
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?
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
Hi,
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
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 = fopen('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.
Hi,
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
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
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
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.
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
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
Derick,
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,
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
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
On Tue, Aug 24, 2021 at 10:15 PM Tobias Nyholm tobias.nyholm@gmail.com
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
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
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
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
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/internalscheers
Dan
Ack
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
On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm tobias.nyholm@gmail.com
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:
- It was a special case of combination types, which voters understood to
be a feature targeting 8.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. - 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
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 pierre.php@gmail.com 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
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
Le mar. 24 août 2021 à 21:09, Derick Rethans derick@php.net a écrit :
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
Le mar. 24 août 2021 à 21:09, Derick Rethans derick@php.net a écrit :
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
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
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.
- 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.
- A Refinement RFC MAY have a shorter discussion period, respecting a
minimum of 10 days, when it's voting ends after feature freeze. - 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:
- 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
Derick Rethans wrote on 8/24/21 12:35:
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.
- 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
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,