We see a relatively high volume of cherry picks that aren't clearly
meeting the criteria for cherry-picking, but that criteria has only
recently started to be in written, shared form and it is not super
discoverable. To make it more clear let's make that its own section
(linkable), move it earlier in the document, and add a table of contents
to the cherry-picks.md for navigation.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
There has been a fair amount of ambiguity, even deliberately, around
what is a valid candidate for backporting to a stable release branch of
Kubernetes. For some the criteria is simply "critical bug fixes", but
this is also something that lacks definition. This documentation update
attempts to better describe what is expected of and what can be expected
by somebody proposing a cherry-pick on one of our stable release branches.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
We're adding a GitHub team for the patch managers and have a group mail
alias to make it easier contacting the folks who shepherd cherry picks
across the arc of time, documented in the release repo.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
Cherry picks are now mostly handled primarily through automation,
including their release note block. In some cases that release
note automation may fail (multiple candidate release notes from
which to pick) and human intervention is required, but this amounts
to just adding the otherwise normal `release-note` block in the
pull request description.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
Kubernetes Prow Robot
Jeffrey Sica
Tim Pepper
guineveresaenger
toyoda
Aaron Crickenberger
eduartua
Nikhita Raghunath