Update release docs to use a label instead of a spreadsheet for backp…

…orts. (pantsbuild#4574)

Also removes the "we are excited to announce Pants 1.0" blurb from the
doc homepage, since we're now releasing 1.3, and that blurb gives the
wrong impression. Also, it's over a year old, so no longer news.

src/docs/index.md

@@ -5,7 +5,6 @@ Pants: A fast, scalable build system
 <img class="index-report-server-page-img" src="images/report-server-page.png" alt="Pants Report Page"
      width="391px" height="246px" />
 
-### We are excited to announce *<a href="1.0.html"><i>Pants 1.0</a>!*
 <br/>
 Pants is a build system designed for codebases that:
 

src/docs/release.md

@@ -119,15 +119,17 @@ the release manager may also need to do a release from a stable branch.*
 * ###Preparation for the release from the stable branch
   See [Release Strategy](http://www.pantsbuild.org/release_strategy.html) for more details about
   whether a release is needed from a stable branch.
-    1. Cherry pick changes that have been identified in the [backport proposals](https://docs.google.com/spreadsheets/d/12rsaVVhmSXrMVlZV6PUu5uzsKNNcceP9Lpf7rpju_IE/edit#gid=0)
-       directly to the stable branch.
+    1. Cherry pick [changes labelled needs-rc-cherrypick](https://github.com/pantsbuild/pants/pulls?q=is%3Apr+label%3Aneeds-rc-cherrypick)
+       directly to the stable branch.  Note that these pull requests must have been merged into master, and
+       therefore will be closed.
     2. In master, update `src/python/pants/notes/*.rst` to reflect all patches that were
        cherry-picked (can use `build-support/bin/release-changelog-helper.sh` to get a head start).
        For example if you were releasing 1.2.0rc1 you would edit `src/python/pants/notes/1.2.x.rst`.
     3. Create and land a review for the notes changes in master.
     4. Cherry pick the merged notes changes from master to the release branch.
     5. In your release branch: edit and commit the version number in `src/python/pants/version.py`.
     6. Execute the release as described later on this page.
+    7. Remove the `needs-rc-cherrypick` label from the changes cherry-picked into the new release.
 
 Dry Run (Optional)
 ------------------

src/docs/release_strategy.md

@@ -29,9 +29,9 @@ justified, it will be either a `major` or `minor` branch (described below).
     * If a new `stable` branch is _not_ created (because of insufficient time/change to justify the
 stable vetting process), the release manager must cut a `dev` release from master instead.
 2. In addition to any `dev` release or newly-created `stable` branches, the release manager should
-determine whether any existing `stable` branches need new release candidates by inspecting the
-[Pants Backport Proposals](https://docs.google.com/spreadsheets/d/12rsaVVhmSXrMVlZV6PUu5uzsKNNcceP9Lpf7rpju_IE/edit#gid=0)
-sheet. If there are requests "sufficient" to justify `patch` releases for existing `stable` branches, the
+determine whether any existing `stable` branches need new release candidates by looking for 
+[changes labelled needs-rc-cherrypick](https://github.com/pantsbuild/pants/pulls?q=is%3Apr+label%3Aneeds-rc-cherrypick).
+If there are requests "sufficient" to justify `patch` releases for existing `stable` branches, the
 release manager should cut release candidates for those branches.
 
 In other words, for a given week: _one of either_ a `dev` or `rc` release will be created from