Skip to content

Latest commit

 

History

History
70 lines (49 loc) · 2.42 KB

cherry-picks.md

File metadata and controls

70 lines (49 loc) · 2.42 KB

WARNING WARNING WARNING WARNING WARNING

PLEASE NOTE: This document applies to the HEAD of the source tree

If you are using a released version of Kubernetes, you should refer to the docs that go with that version.

The latest 1.0.x release of this document can be found [here](http://releases.k8s.io/release-1.0/docs/devel/cherry-picks.md).

Documentation for other releases can be found at releases.k8s.io.

Overview

This document explains cherry picks are managed on release branches within the Kubernetes projects.

Propose a Cherry Pick

Any contributor can propose a cherry pick of any pull request, like so:

hack/cherry_pick_pull.sh upstream/release-3.14 98765

This will walk you through the steps to propose an automated cherry pick of pull #98765 for remote branch upstream/release-3.14.

Cherry Pick Review

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.

Searching for Cherry Picks

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

Analytics