Hello Pulsar Community,

As far as I can tell, we do not have a publicly defined process for
cherry-picking commits to release branches [0]. As a new committer,
I'd like to provide my newly gained perspective and ask that we add
some guidance to our wiki.

Regarding cherry picking, I see two patterns in Pulsar:
1. Some committers cherry pick commits when they merge a PR.
2. Some committers leave PRs to be cherry picked right before tagging
the dot release. The release manager is expected to cherry pick these
commits.

Anecdotally, pattern 2 is more common.

I am concerned that pattern 2 creates a lot of extra work for the
release manager, leaves the community with little time to build and
test release branches before tagging release candidates, and leaves us
unable to quickly respond to security issues.

If we switch to pattern 1, merging PRs may become more time consuming.
However, it lightens the load on release managers and makes the
project more nimble. Further, resolving conflicts should be easier, as
the committer already has the PR's context, which could reduce the
risk of regressions.

For example, the 2.7.4 release is delayed because of pattern 2.
Penghui and I cherry picked many commits over the recent days because
branch-2.7 was not up to date. Now, the tests aren't passing for the
branch, and since we shouldn't cut a release until the tests pass, we
haven't released the patch for the Log4Shell CVE.

Another solution is to remove the expectation that the release manager
cherry picks commits. The downside here is that we will possibly miss
important bug fixes that would improve dot release stability.

I propose that we try to use pattern 1 (or something close to it) for
our process.

Thanks,
Michael

[0] https://github.com/apache/pulsar/wiki/Committer-Guide

Reply via email to