Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] PR Cherrypicking Process After a Release Branch Cut #7203

Open
lsy323 opened this issue Jun 5, 2024 · 1 comment
Open

[RFC] PR Cherrypicking Process After a Release Branch Cut #7203

lsy323 opened this issue Jun 5, 2024 · 1 comment
Labels

Comments

@lsy323
Copy link
Collaborator

lsy323 commented Jun 5, 2024

🚀 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
@lsy323 lsy323 added the RFC label Jun 5, 2024
@miladm miladm pinned this issue Jun 6, 2024
@miladm miladm changed the title [RFC] Policy on accepting cherrypicking PRs after release branch cut [RFC] PR Cherrypicking Process After a Release Branch Cut Jun 6, 2024
@JackCaoG
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants