This is an archived version of the documentation. View the latest version here.
This document explains cherry picks are managed on release branches within the Kubernetes projects.
Any contributor can propose a cherry pick of any pull request, like so:
hack/cherry_pick_pull.sh upstream/release-3.14 98765This will walk you through the steps to propose an automated cherry pick of pull
#98765 for remote branch upstream/release-3.14.
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.
Contributor License Agreements is considered implicit for all code within cherry-pick pull requests, unless there is a large conflict.
Now that we've structured cherry picks as PRs, searching for all cherry-picks against a release is a GitHub query: For example, this query is all of the v0.21.x cherry-picks