Re: Important Reminders to Apache Pulsar committers for PR Merging and Release Management

[Lari Hotari <lh...@apache.org>]

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/
>