Hi Nicolas, Le jeu. 19 août 2021 à 12:25, Nicolas Grekas <nicolas.gre...@gmail.com> a écrit :
> What a mess! I feel so disappointed by the lack of clarity of the > processes here. > You aren't alone and it is challenging to make that kind of decision. I would have been more confident saying it's ok if the process and feature freeze was clear about the fact that even syntax changes are allowed a couple of days before a RC1 provided that it touches a new feature. > The RFC was granted a "go" by a release manager, but suddenly, in the > middle of the vote, another release manager raised an objection to this > grant!? > I'm sorry for the timing and I was also not aware of it. > This should have been discussed before between release managers. > Agreed! That would have been ideal. > Also, this "go" is now apparently revoked based on the partial results of > the vote. This is obviously interfering with the vote itself! I'm not > blaming any individuals, but some processes should clarify how this is > supposed to work. At least please coordinate together on such topics! 🙏 > > The processes also lack clarity about what the feature freeze is supposed > to mean. We're having a metadiscussion about whether this RFC can target > 8.1 or not, and many ppl stated that they would vote against it not because > they don't want nullability, but because they don't want it in 8.1, or > because they feel it's too late for 8.1. I can't blame them for that, but > what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > I share with you the lack of clarity. Commenting on the various aspects of feature freeze (personal pov): - discuss: discussing shouldn't be prevented in any way, never. - alter: that is the most touchy part as alteration might be about very various levels: edge cases, implementation details, conceptual ones, syntax,... In a feature freeze, I would only consider minor changes that wouldn't have influenced the way people would have voted the RFC. That would exclude any conceptual changes as well as syntax ones. - revert: if there are evidence that something that has been voted "yes" really brings unforeseen challenges and provided that a majority would recognize something that has been accepted should better be reverted, I think we must be open to revert the introduction of a new feature: better not having a new (buggy?) feature than a solid one later. In the case of your new RFC: I rather see it as another feature on top of a new one that even requires syntax changes. It may prove that the original one was not rock-solid enough but it may also be seen as an extension of it. > This should be shielded by some consensus on what is allowed during the > feature freeze. On my side: anything that is not yet released should be > re-discussable until either beta or RC stage. If we choose to go with beta, > we should give more time between the start of the feature freeze and the > first beta, precisely to fix what happened to this RFC, aka to give a > window for the community (me here) to play with the soon-to-be features and > give feedback. > Either extra time, or having a way to influence the schedule of the releases. For now, we work with a fixed schedule and don't know (at least: me) how strict we must stick to it. The fixed schedule of the releases is what makes me more comfortable with the idea of reverting a new feature rather than extending the scope of one. > Based on the partial results of the vote, we could conclude that the > consensus is to 1. not allow nullability and 2. force bracket around > (X&Y)|null. I can't read this as anything else than ppl voting not on the > RFC, but on this metadiscussion about the feature freeze + some fear that > we might put ourselves in a corner with the syntax. > > The RFC should be allowed to complete, it's gathering important data. >> > > Because of what I just wrote about, I don't think we can rely on any data > here. The discussion should be rebooted from scratch for me. Apparently, we > need the full syntax for composite types to decide for the syntax for > nullable intersection types. ¯\_(ツ)_/¯ > I also think that we can't rely on the data for the reason you mention even if I intended to vote "no" on the feature, not on the targeted version of PHP, I may be the exception there. > Now, I don't know what to do. The vote started and is not looking good for > the proposal. Some will say that I didn't want to see it fail if I withdraw > it. But honestly, with all those interferences, I'm not sure the conditions > are met to have a fair vote. > I understand you Nicolas. Let me and the other RMs have a chat about that so that we explore all the possible options > Please advise (release managers mainly I suppose, since you're the only > ones having some sort of official authority here). > > Nicolas > Cheers, Patrick
