This is now documented at https://pulsar.apache.org/contribute/maintenance-process/ Contributions are welcome to improve this starting point.
-Lari On 2024/08/21 12:26:08 Lari Hotari wrote: > Dear Apache Pulsar Committers, > > I hope this email finds you well. I wanted to share some important reminders > regarding PR merging and release management. This reminder is for Apache > Pulsar committers since they have access for these tasks. Please take a > moment to review the following information: > > Labeling PRs for Release Branches > > Before merging a PR, please ensure you label the releases where the PR should > also be applied. Our current process involves adding release labels for the > next pending releases so that we also cherry-pick fixes to maintenance > branches. > > Always label non-breaking fixes to the supported maintenance version branches > (currently branch-3.0 and branch-3.3). Right now 3.0.7 is the next release > for branch-3.0 and 3.3.1 is the next release for branch-3.3. The respective > PR labels are release/3.0.7 and release/3.3.1. > > These labels are crucial for searching PRs that need to be cherry-picked > during the release process. > > Cherry-picking Process > > The cherry-picking process is partially explained in our release process > documentation: > https://pulsar.apache.org/contribute/release-process/#cherry-picking-changes-scheduled-for-the-release > There's an ongoing discussion about improving this process: > https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv > > Current Process and Responsibilities > > It's sufficient to add the labels while merging. This is the expectation for > the Apache Pulsar committer that merges a PR. A PR shouldn't be merged > without checking that it contains the necessary labels. > > Committers actively working as release managers will handle cherry-picking > and backporting. > Release managers will request specific backports when a PR cannot be easily > backported due to merge conflicts. > > Cherry-picking > > Cherry-picks should be performed in the same order as the PRs were merged in > the master branch. > This is necessary to reduce unnecessary merge conflicts in maintenance > branches. > Cherry-picking should retain a reference to the original commit. This can be > achieved by passing the "-x" argument so that cherry-picks are performed with > "git cherry-pick -x <commit hash>" command. > > Handling Merge Conflicts > > Merge conflicts are common, and it's necessary to understand the tooling and > process to handle conflict resolution. Please refer to > https://pulsar.apache.org/contribute/setup-git/ for suggestions on setting up > git with proper merge & diff tools for maintaining Pulsar. > > In cases where a PR cannot be applied without substantial backporting effort > or risk of breaking changes, a separate PR to the maintenance branch is > requested from the original PR author. If the author is not willing to do > this work, the release manager attempts to find a volunteer to handle this. > > In some cases, a large number of merge conflict signals that there's a > dependent PR that is needed also in the maintenance branch which hasn't been > cherry-picked. It is useful to review the dependency and consider > cherry-picking it. Only non-breaking bug fixes or minor improvements > (excludes PIP related changes) can be cherry-picked without discussion on the > dev mailing list. Backporting is necessary when a fix depends on newer PIP > related changes. > > Call for Volunteers > > We're looking for volunteers to help with these tasks. If you're interested > in the release manager role for upcoming Pulsar releases, please: > > - Suggest it on this dev mailing list, or > - Express interest on the Pulsar Slack #dev channel > > I'm one of the committers who can help with various Pulsar release > maintenance tasks. Feel free to ping me or others on the Pulsar Slack #dev > channel for assistance. > > We're excited to welcome new volunteers to sign up and contribute to these > important processes! > We are looking for volunteers that are already Apache Pulsar committers since > that is a requirement for performing release management tasks. > > There are plenty of contribution opportunities for volunteers that aren't yet > Apache Pulsar committers. There's a separate page about becoming a Apache > Pulsar core developer and committer [1]. > > Best regards, > > Lari > > [1] https://pulsar.apache.org/contribute/become-core-developer/ >
