This document explains how cherry picks are managed on release branches within the Kubernetes projects. A common use case for this task is for backporting PRs from master to release branches.
originfork on GitHub and making a pull request against a configured remote
upstreamthat tracks “https://github.com/kubernetes/kubernetes.git", including
hubinstalled, which is most easily installed via
go get github.com/github/hubassuming you have a standard golang development environment.
hack/cherry_pick_pull.sh upstream/release-3.14 98765
do-not-merge/cherry-pick-not-approvedlabel. The release branch owner will triage PRs targeted to the branch. Normal rules apply for code merge.
/approveas they deem appropriate.
Cherry pick pull requests are reviewed differently than normal pull requests. In particular, they may be self-merged by the release branch owner without fanfare, in the case the release branch owner knows the cherry pick was already requested - this should not be the norm, but it may happen.
See the cherrypick queue dashboard for
status of PRs labeled as