Hi Yunze, Thanks for bringing this discussion. I agree that there must be some step to remind everybody that a code freeze is coming and that people should pay attention to their open PRs if they want them included. In a sense Zike's mail one week ago did this and was pretty clear on what was going to happen. Nobody reacted to it with concern on their open PR, so I guess there's no important one that can't wait for 3.1. So I think we should go on with the code freeze as planned. If anyone has a PR that they really want to see included and have real motivation to not wait 3.1, please express it as soon as possible here. The StreamingDispatcher removal (or deprecation?) could well be one of those PRs but it should be decided very quickly. Also I want to remind that this release will already be a huge one with features that have been merged into main in August and I think we shouldn't add potential delays without care.
Thanks, Christophe Le lun. 10 avr. 2023 à 04:56, Yunze Xu <y...@streamnative.io.invalid> a écrit : > > Hi community, > > I see the code freeze of Pulsar 3.0.0 is coming tomorrow. But I found > the release process still lacks a key step that pending PRs should be > taken carefully of instead of simply delaying them to the next > release. > > The following cases were very often seen: > 1. A PR has opened for some days and no one reviewed it. > 2. A reviewer left some comments and the author disappeared for some time. > 3. The author of a PR has addressed the requested changes but the > reviewer has disappeared for some time. > > As we know, Apache committers are volunteers and have their own jobs. > So the cases above are all acceptable. However, before a release, I > think the release managers must take the responsibility to handle the > cases above. > > IMO, we must address the cases about (at least 1 and 3 are > controllable) one week in advance. If the PR cannot be merged due to > the disappearance of the author, it's okay to delay it to the next > release. But the release managers should address the PRs actively. > They can help review the PRs. Or at least, > - for case 1: they can ping some committers that are familiar with the > scope of the PR to review it. > - for case 2: they can ping the author > - for case 3: they can ping the reviewer > > I see Zike noticed the time point of the code freeze last week: > https://lists.apache.org/thread/tczgh4y8lcy2y85652vkctbkcrs40nq4. But > there is no clear process for how to process the pending PRs before > the code freeze. > > Thanks, > Yunze
