On Thu, Aug 19, 2021 at 12:25 PM Nicolas Grekas <nicolas.gre...@gmail.com> wrote:
> What a mess! I feel so disappointed by the lack of clarity of the > processes here. > > 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!? This should have been discussed before between release managers. > 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?!? 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. > > 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. ¯\_(ツ)_/¯ > > 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. > > Please advise (release managers mainly I suppose, since you're the only > ones having some sort of official authority here). > > Nicolas > All things considered I think the outcome was somewhat expected. The grant given was "with the best knowledge at the time of the grant" which obviously is subject to change given how much discussion happened for the RFC. The discussion presented resistance to the change and the vote reflects the sentiment around the discussion. The fact that the process could be better doesn't make it a mess. Ultimately, the language syntax is how we communicate with the computer and more importantly how we read and understand the code. It has a great impact on code using `token_get_all()` and is always a delicate matter. An RFC targeting controversial syntax change in post feature-freeze is ... challenging. -- Marco Aurélio Deleu
