kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clarify cherry-pick candidates

This commit is contained in:
Jordan Liggitt 2024-10-14 10:18:56 -04:00
parent bb2de367d3
commit 42002f6cce
No known key found for this signature in database
1 changed files with 14 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
contributors/devel/sig-release/cherry-picks.md
View File

@ -32,22 +32,23 @@ branches.
## What Kind of PRs are Good for Cherry Picks ## What Kind of PRs are Good for Cherry Picks
Compared to the normal master branch's merge volume across time, Patch releases must be easy and safe to consume, so security fixes
the release branches see one or two orders of magnitude less PRs. and critical bugfixes can be delivered with minimal risk of regression.
This is because there is an order or two of magnitude higher scrutiny.
Again, the emphasis is on critical bug fixes, e.g.,
- Loss of data Only the following types of changes are expected to be backported:
- Memory corruption
- Panic, crash, hang
- Security
A bugfix for a functional issue (not a data loss or security issue) that only - Security fixes
affects an alpha feature does not qualify as a critical bug fix. - Dependency updates that just aim to silence some scanners
and do not fix any vulnerable code are **not** eligible for cherry-picks.
- Regression fixes
- Critical bug fixes (loss of data, memory corruption, panic, crash, hang)
- A bugfix for a functional issue (not a data loss or security issue) that only
affects an alpha feature does not qualify as a critical bug fix.
- Prerequisite changes for critical dependency updates (e.g. [go updates](https://github.com/kubernetes/sig-release/blob/master/release-engineering/handbooks/go.md#minor-version-updates))
- Test-only changes to stabilize failing / flaky tests on release branches
If you are proposing a cherry pick and it is not a clear and obvious critical If you are proposing a cherry pick outside these categories, please reconsider.
bug fix, please reconsider. If upon reflection you wish to continue, bolster If upon reflection you wish to continue, bolster your case by supplementing your PR with e.g.,
your case by supplementing your PR with e.g.,
- A GitHub issue detailing the problem - A GitHub issue detailing the problem
@ -62,21 +63,6 @@ your case by supplementing your PR with e.g.,
- Key stakeholder SIG reviewers/approvers attesting to their confidence in the - Key stakeholder SIG reviewers/approvers attesting to their confidence in the
change being a required backport change being a required backport
To illustrate the point, dependency updates that just aim to silence some scanners
and do not fix any vulnerable code are NOT eligible for cherry-picks.
If the change is in cloud provider-specific platform code (which is in the
process of being moved out of core Kubernetes), describe the customer impact,
how the issue escaped initial testing, remediation taken to prevent similar
future escapes, and why the change cannot be carried in your downstream fork of
the Kubernetes project branches.
It is critical that our full community is actively engaged on enhancements in
the project. If a released feature was not enabled on a particular provider's
platform, this is a community miss that needs to be resolved in the `master`
branch for subsequent releases. Such enabling will not be backported to the
patch release branches.
## Initiate a Cherry Pick ## Initiate a Cherry Pick
### Before you begin ### Before you begin