Sync up all release note related docs with the latest process/procedures.

docs/devel/cherry-picks.md

@@ -41,14 +41,15 @@ depending on the point in the release cycle.
 ## Propose a Cherry Pick
 
 1. Cherrypicks are [managed with labels and milestones](pull-requests.md#release-notes)
-
 1. All label/milestone accounting happens on PRs on master.  There's nothing to do on PRs targeted to the release branches.
 1. When you want a PR to be merged to the release branch, make the following label changes to the **master** branch PR:
-
   * Remove release-note-label-needed
   * Add an appropriate release-note-(!label-needed) label
   * Add an appropriate milestone
   * Add the `cherrypick-candidate` label
+  * The PR title is the **release note** you want published at release time and
+    note that PR titles are mutable and should reflect a release note
+    friendly message for any `release-note-*` labeled PRs.
 
 ### How do cherrypick-candidates make it to the release branch?
 

docs/devel/pull-requests.md

@@ -38,6 +38,7 @@ Documentation for other releases can be found at
 - [Life of a Pull Request](#life-of-a-pull-request)
   - [Before sending a pull request](#before-sending-a-pull-request)
   - [Release Notes](#release-notes)
+    - [Reviewing pre-release notes](#reviewing-pre-release-notes)
   - [Visual overview](#visual-overview)
 - [Other notes](#other-notes)
 - [Automation](#automation)
@@ -73,12 +74,34 @@ The following will save time for both you and your reviewer:
 
 ## Release Notes
 
-1. Your PR title is the **release note** you want published at release time.
-1. Release note labels are only needed on master branch PRs.
+This section applies only to pull requests on the master branch.
+
 1. All pull requests are initiated with a `release-note-label-needed` label.
 1. For a PR to be ready to merge, the `release-note-label-needed` label must be removed and one of the other `release-note-*` labels must be added.
 1. `release-note-none` is a valid option if the PR does not need to be mentioned
  at release time.
+1. The PR title is the **release note** you want published at release time.
+  * NOTE: PR titles are mutable and should reflect a release note friendly
+    message for any `release-note-*` labeled PRs.
+
+The only exception to these rules is when a PR is not a cherry-pick and is
+targeted directly to the non-master branch.  In this case, a `release-note-*`
+label is optional (and not enforced).
+
+### Reviewing pre-release notes
+
+**NOTE: THIS TOOLING IS NOT YET AVAILABLE, BUT COMING SOON!**
+
+At any time, you can see what the release notes will look like on any branch.
+
+```
+$ git pull https://github.com/kubernetes/release
+$ RELNOTES=$PWD/release/relnotes
+$ cd /to/your/kubernetes/repo
+$ $RELNOTES -man # for details on how to use the tool
+# Show release notes from the last release on a branch to HEAD
+$ $RELNOTES --raw --branch=master
+```
 
 ## Visual overview
 

docs/proposals/release-notes.md

@@ -31,7 +31,7 @@ Documentation for other releases can be found at
 # Kubernetes Release Notes
 
 [djmm@google.com](mailto:djmm@google.com)<BR>
-Last Updated: 2016-3-25
+Last Updated: 2016-04-06
 
 <!-- BEGIN MUNGE: GENERATED_TOC -->
 
@@ -115,14 +115,19 @@ hundreds of entries.  The goal is to highlight the major changes for a release.
 
 The munger/bot option fits most cleanly into the existing workflow.
 
-The design will include:
+All `release-note-*` labeling is managed on the master branch PR only.
+No `release-note-*` labels are needed on cherry-pick PRs and no information
+will be collected from that cherry-pick PR.
+
+The only exception to this rule is when a PR is not a cherry-pick and is
+targeted directly to the non-master branch.  In this case, a `release-note-*`
+label is optional (and not enforced).
 
 1. New labels added to github: `release-note-none`, maybe others for new release note categories - see Layout section below
 1. A [new munger](https://github.com/kubernetes/kubernetes/issues/23409) that will:
-  * Initiate a `release-note-needed` label on all new PRs
-  * Block merge by the submit queue on all PRs labeled as `release-note-needed`
-  * Auto-remove `release-note-needed` when one of the release-note-\* labels is added
-  * Special case for cherry-picked/branch PRs, release-note-none is not allowed
+  * Add a `release-note-label-needed` label to all new master branch PRs
+  * Block merge by the submit queue on all PRs labeled as `release-note-label-needed`
+  * Auto-remove `release-note-label-needed` when one of the `release-note-*` labels is added
 
 ## Publishing Design