Hi Yunze, Thank you for bringing up this critical issue regarding pending PRs before the code freeze. I appreciate your thoughtful insights and suggestions.
I'd like to share my thoughts on this. In previous releases, we didn't have a formal code freeze announcement; instead, we had a discussion email. The release manager would notify everyone when the cherry-picking process was complete and ask if there were any other PRs that needed to be included. After waiting for some time, the release manager would then create an RC label, and any PRs cherry-picked after this label would not be included in the release. In light of your suggestions, I believe we can carefully review the PRs cherry-picked after the discussion email and before sending a code freeze email. This can help us avoid potential issues caused by someone overlooking the discussion email and cherry-picking PRs that should not be included or introducing other unstable factors. By adopting these changes, we can address the concerns you've raised and improve the overall release process. Thank you again for raising this concern, and I'm confident that implementing these improvements will be beneficial for our community. Best regards, Xiangying 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 >
