Hi, Yunze, Thanks for raising this discussion. It's good to have the phase to proceed with the PR reviewing and merging before the code freeze.
> But the release managers should address the PRs actively. > They can help review the PRs. Or at least, I think we should separate these two roles: Release Managers and Code Reviewers. The case 1 and 3 are also not controllable for the release manager. But I'm +1 for the release manager should help advance this phase. > we can send a discussion thread one week before the code freeze. Then, > 1. The PRs opened after the time point won't be considered to be > included in this release > 2. If someone has some pending PRs that are aimed to be included in > this release, it's better to comment in the discussion thread. +1. Looks like it's more like a PR-freeze time point. I think the timeline `one week before the code freeze` could be further discussed. Thanks, Zike Yang Zike Yang On Mon, Apr 10, 2023 at 11:11 AM Yunze Xu <y...@streamnative.io.invalid> wrote: > > To be more specific, we can send a discussion thread one week before > the code freeze. Then, > 1. The PRs opened after the time point won't be considered to be > included in this release > 2. If someone has some pending PRs that are aimed to be included in > this release, it's better to comment in the discussion thread. > > For example, [1] aimed to drop the streaming dispatcher in 3.0.0. > However, there was no PR yet. If the PR was opened today and merged > very quickly, there might not be enough time to complete the review > process. We cannot assume a PR won't receive any request change. > > [1] https://lists.apache.org/thread/ky2bkzlz93njx3ntnvkpd0l77qzzgcmv > > Thanks, > Yunze > > On Mon, Apr 10, 2023 at 10:56 AM Yunze Xu <y...@streamnative.io> wrote: > > > > 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
