> > On Mon, 16 Aug 2021 at 10:04, Nikita Popov <nikita....@gmail.com> wrote: > >> On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins <krak...@gmail.com> wrote: >> >>> Morning all, >>> >>> The initial RFC was clear that nullability was not supported, however >>> that >>> doesn't seem to be have widely understood. >>> >>> When I said we should move forward I did imagine that there was some >>> consensus about the syntax we should use if we were to support >>> nullability. >>> >> >> Based on the vote, it looks like there's a pretty clear consensus on >> (X&Y)|null :) >> >> >>> As this conversation has progressed it has become clear that we don't >>> have >>> that consensus, and many people are just not comfortable trying to build >>> consensus this late in the cycle. >>> >>> The RFC is not passing currently so I don't think we actually need to do >>> anything, except prepare to deploy the feature that was voted in, pure >>> intersections. >>> >>> The RFC should be allowed to complete, it's gathering important data. >>> >>> In the end, I'm not as happy to make an exception as I was when the >>> discussion started. >> >> >> FWIW I think that if we granted an exception for this once, we shouldn't >> go back on it. Maybe there should have been some discussion among RMs about >> this, but I think your agreement was interpreted (at least by me and >> presumably Nicolas) as it being fine to go forward with this RFC from a >> release management perspective. Now that the vote is underway, people can >> take the fact that this is targeting 8.1 into consideration in their choice >> -- I suspect that a lot of the "no" votes here are specifically due to >> that, not because they generally dislike support for nullable intersection >> types. >> >> 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. (Of course, in this >> particular case the proposed change is backwards-compatible, so there is no >> strict requirement to make a change before the stable release.) >> >> Regards, >> Nikita >> > Morning Nikita, all, > > The exception was granted to ratify consensus that I thought we had - and > that one of the two primary votes on the current RFC seems to support. > > However, the RFC we got was something that contained multiple primary > votes - we must consider the first two votes primary, we don't want to > choose syntax on a 50% majority. > > At the moment it looks like we don't have a consensus that adding > nullability (at this late stage) is important. > > I too think it's important to be flexible in this stage of the cycle, but > I look at the opposition to making this change now and that degrades my > confidence that making the change this late even if it does pass is a good > idea. > > Cheers > Joe >
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
