feat(docs): update backport documentation

community/contributing/releasing/index.md

@@ -21,11 +21,14 @@ include all commits merged into `master` for each service. We do this on a
 
 In order to be considered safe to merge into a release branch, your patch must:
 
-* Fix a documented regression. This means that the currently broken
-  functionality must have worked as expected in a previous version of Spinnaker.
-  If the regression is not already documented in a GitHub issue, please create
-  one. Describe the difference between the expected and observed behavior, and
-  include links to the commit(s) that introduced the regression.
+* Fix a documented regression in a
+  [supported version of Spinnaker](https://spinnaker.io/community/releases/versions/#latest-stable).
+  This means that the currently broken functionality must have worked as
+  expected in a previous version of Spinnaker. If the regression is not already
+  documented in a GitHub issue, please create one. Describe the difference
+  between the expected and observed behavior, and include links to the commit
+  that introduced the regression. Indicate to which releases you would like
+  your fix to be backported.
 * Include tests validating the regression and the fix. The first commit of your
   patch pull request should add test coverage that demonstrates the existence
   of the bug and exercises all code paths potentially impacted by your fix.
@@ -45,56 +48,15 @@ release branch. For example, all Spinnaker 1.16 releases (1.16.0, 1.16.1, etc.)
 are built from the `release-1.16.x` release branch. To get your patch into 1.16,
 it must be cherry-picked onto that release branch.
 
-There are two ways to create a pull request for a cherry-pick:
+After you've created a pull request for a fix that you want backported to a release
+branch, add a comment that includes the following:
 
-* [Using Mergify](#cherry-pick-using-mergify)
-* [Manually via the command-line](#cherry-pick-using-the-command-line)
-
-After creating a cherry-pick pull request, you should assign the review to the
-current release manager. The release manager rotation calendar is currently only
-available inside Google, but it only rotates every eight weeks. The release
-manager will be the person posting about the releases in [the
-`#spinnaker-releases` Slack
-channel](https://app.slack.com/client/T091CRSGH/CHD4ATAMV/).
+> @spinnakerbot add-label backport-candidate
 
+Release managers will audit all PRs with the `backport-candidate` label weekly.
 Please make sure your pull request description makes it easy for the release
 manager to evaluate whether your patch meets the release branch patch criteria.
 
-## Cherry-pick using Mergify
-
-To cherry-pick into the `1.18` release branch (for example), mention the `@spinnaker/release-managers`
-to have them add the following comment to the _merged_ PR for your change:
-
-> @Mergifyio backport release-1.18.x
-
-Later improvements will allow anyone to execute the backport command, a [feature request has been submitted](https://github.com/Mergifyio/mergify-engine/issues/1070) to Mergify.
-
-
-## Cherry-pick using the command line
-
-For example: say you've fixed a bug and had the fix merged into master. You're
-running Spinnaker 1.5.1, and want the fix in Spinnaker 1.5.2. First, find the
-commit's hash. This is easy to do in the "Commits" tab in your repository:
-
-{% include figure image_path="./commit.png" caption="The hash is `a090bf3` in
-this example" %}
-
-Now, in your cloned repository run:
-
-```bash
-# the branch depends on your target release
-git fetch upstream release-1.5.x
-
-git checkout upstream/release-1.5.x
-
-# the commit depends on what you found in the "Commits" tab above
-git cherry-pick a090bf3
-
-git checkout -b patch-broken-creds
-
-git push origin patch-broken-creds
-```
-
 Navigate to GitHub, and create a PR as you would normally, but make sure that
 your "base" is set to the release branch in the upstream repository as shown
 below:

community/releases/release-manager-runbook/index.md

@@ -167,11 +167,7 @@ release candidate is now validated and can be tested.
 
 ## One week after branches are cut (Monday)
 
-1. Check for any PRs waiting to be [cherry-picked](https://github.com/pulls?utf8=%E2%9C%93&q=org%3Aspinnaker+is%3Apr+is%3Aopen+-base%3Amaster).
-(You can further restrict the query by adding a constraint like +base:release-1.18.x to the URL.)
-Ensure patches meet the
-[release branch patch criteria](/community/contributing/releasing#release-branch-patch-criteria)
-before merging.
+1. Audit [backport candidates](#audit-backport-candidates).
 
 1. Rerun the `Flow_BuildAndValidate_${RELEASE}` job and get a blue build.
 
@@ -306,11 +302,10 @@ Example: VERSION="1.17.2" ./publish.sh
 
 Repeat weeklyish for each supported version.
 
-1. Check for any PRs waiting to be [cherry-picked](https://github.com/pulls?utf8=%E2%9C%93&q=org%3Aspinnaker+is%3Apr+is%3Aopen+-base%3Amaster).
-(You can further restrict the query by adding a constraint like +base:release-1.18.x to the URL.)
-Ensure patches meet the
-[release branch patch criteria](/community/contributing/releasing#release-branch-patch-criteria)
-before merging. To view what's been merged into the each release branch since the last release, see the [changelog gist](https://gist.github.com/spinnaker-release/4f8cd09490870ae9ebf78be3be1763ee) on Github.
+1. Audit [backport candidates](#audit-backport-candidates).
+To view what's been merged into each release branch since the last release,
+see the [changelog gist](https://gist.github.com/spinnaker-release/4f8cd09490870ae9ebf78be3be1763ee)
+on Github.
 
 1. Rerun the `Flow_BuildAndValidate_${RELEASE}` job and get a blue build.
 
@@ -390,12 +385,8 @@ https://builds.spinnaker.io/job/Build_PrimaryArtifacts/${JOB_NUMBER}/artifact/bu
 
 Repeat as needed.
 
-1. Check for any PRs waiting to be [cherry-picked](https://github.com/spinnaker/halyard/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-base%3Amaster).
-(You can further restrict the query by adding a constraint like +base:release-1.18.x to the URL.)
-Ensure patches meet the
-[release branch patch criteria](/community/contributing/releasing#release-branch-patch-criteria)
-before merging.
-
+1. Ensure you have [audited](#audit-backport-candidates) all
+[Halyard backport candidates](https://github.com/spinnaker/halyard/pulls?q=is%3Apr+sort%3Aupdated-desc+label%3Abackport-candidate).
 
 1. Run Build_Halyard:
 
@@ -423,3 +414,39 @@ Repeat as needed.
 
 Follow the instructions in deck-kayenta’s
 [README](https://github.com/spinnaker/deck-kayenta#publishing-spinnakerkayenta).
+
+## Audit backport candidates
+
+Repeat weekly.
+
+1. Audit each PR that has been labelled a
+[backport candidate](https://github.com/pulls?q=org%3Aspinnaker+is%3Apr+sort%3Aupdated-desc+label%3Abackport-candidate).
+
+1. If a candidate meets the
+[release branch patch criteria](/community/contributing/releasing#release-branch-patch-criteria):
+
+    1. Remove the `backport-candidate` label from the PR.
+
+    1. Add a comment instructing
+       [Mergify](https://doc.mergify.io/commands.html#backport) to create
+       backport PRs against one or more release branches. For example, to
+       create backport PRs against the 1.20 and 1.21 release branches, comment:
+
+       > @Mergifyio backport release-1.20.x release-1.21.x
+
+    1. Approve and merge the backport PRs.
+
+    1. If Mergify cannot create a backport because there are merge conflicts,
+       ask the contributor to open a PR against the target release branches with
+       their commits manually
+       [cherry-picked](https://git-scm.com/docs/git-cherry-pick).
+
+1. If a candidate does not meet the
+[release branch patch criteria](/community/contributing/releasing#release-branch-patch-criteria),
+add an explanation to the contributor as a comment.
+
+    1. If it's impossible for the candidate to meet the criteria (for example, it doesn't
+       fix a regression), remove the `backport-candidate` label.
+
+    1. If the contributor can amend the candidate to meet the criteria (for example,
+       add test coverage), don't remove the `backport-candidate` label.