[RFC] PR Cherrypicking Process After a Release Branch Cut

[lsy323]

🚀 Feature

In this RFC, we propose the policy aiming to guide the decision-making process for determining whether Pull Requests (PRs) should be cherry-picked onto a release branch after the release branch has been cut. The goal is to maintain the stability and predictability of releases while addressing critical issues and incorporating essential improvements.

Motivation

Cherry-picking pull requests (PRs) onto a release branch can introduce additional overhead and goes against established best practices. While cherry-picks are sometimes unavoidable, we can mitigate their necessity through well-defined policies. This proposal outlines a framework for making informed decisions about when and how to cherry-pick changes.

Proposed Policies:

The following outlines the specific scenarios under which cherry-picking pull requests (PRs) onto a release branch will be considered acceptable after the official release branch cut.

• The PR is for severe/P0 bug fixing purposes
• The PR is for improving unforeseen code stability or security issues
• The PR has significant impact on usability improvements
• The PR is related to a planned release feature urgent fix
• The PR only updates documentation, not changing any code
• The PR is for improving release infrastructure

[JackCaoG]

couple thing I think we should consider

1. The merge rule should be more strict as the release deadline approaches. For the first 1-2 week we can still consider taking features that's critical to the user/customer.
2. For features that can be turned off by a flag or not enabled by default we should consider them as safer. Features that will affect the default behavior of the PyTorch/XLA is dangerous and shouldn't be taken after release unless it is a regression fix.
3. The bar for the experimental feature can be lower since we set the user expection. The changes to a already stable feature should be more carefully review.