[upstream] Add Stable Release info to Release Cycle Slides

During the Boston Summit education session there were
questions about stable branches during the 'Release Cycle'
presentation.  We decided it would be good to add slides for
this to that presentation.

This patch adds those slides.  Also, it appears that the way
that ReST is processed by the latest tooling is slightly different.
If you don't have spaces before and after an indented section it
doesn't indent the bullets.  This patch fixes that for this
set of slides as well.

There was also some awkward wording that was caught in review.
This fixes those issues as well.

Change-Id: I9981f661f4a82b4b4c9a5591f88d5039a3671fc4

doc/upstream-training/source/slides/howitsmade-release-cycle.rst

@@ -31,15 +31,20 @@ What makes a release
     milestones as that is what most students will work with. The other types
     should be described.
   - Common cycle with intermediary release:
+
     - Used for components needing more frequent releases. e.g. Oslo Libraries
     - Intermediary releases can also be used to time releases near the
-    beginning and end of the release cycle. Horizon plug-ins do this.
+      beginning and end of the release cycle. Horizon plug-ins do this.
+
   - Trailing the common cycle:
+
     - Projects dependent upon the output of a release, like packaging or
-    deploying OpenStack follow this model; e.g. Fuel and Kolla
+      deploying OpenStack follow this model; e.g. Fuel and Kolla
+
   - Independent release model:
-    - These projects may hold tools used for OpenStack part aren't part of a
-    production release.
+
+    - These projects may hold tools used for OpenStack but are not part of a
+      production release.
 
 Exercise
 ========
@@ -172,15 +177,22 @@ Exercise
 .. note::
 
   - Spec freeze
+
     - Point at which specs must be proposed and reviewed for the release.
+
   - Feature freeze
+
     - Code for new features is no longer accepted.
+
   - String freeze
+
     - Externally visible strings can no longer be changed. Helps translation
-    activities complete on time.
+      activities complete on time.
+
   - Requirements freeze
-    - No longer change requirements to allow downstream packagers time to
-    pull-in and build dependencies.
+
+    - Requirements cannot be changed to allow downstream packagers time to
+      pull-in and build dependencies.
 
 Release Candidates
 ==================
@@ -200,9 +212,11 @@ Release Candidates
 .. note::
 
   - Code change during the RC phase is a balancing act
+
     - Need to balance integrating fixes and code churn
     - Critical fixes have the highest priority while more minor bug fixes may
-    be safer to hold for the subsequent release.
+      be safer to hold for the subsequent release.
+
   - Who is able to approve patches during the RC phase is limited.
 
 Release candidate process
@@ -214,6 +228,7 @@ Release candidate process
 - Used as-is as the final release
 - Additional Release Candidates created for critical bugs found during
   RC testing
+
   - (RC2, RC3, ...) with bugs targeted to it
   - Repeated as many times as necessary
 
@@ -229,4 +244,46 @@ Exercise
 - Find the release day for the current release
 - Find where the currently released code is posted
 
+Stable Branch
+=============
 
+- Name for a cycle that has been released
+- Projects that follow some form of the 'Common' release
+  cycle have branches like 'stable/<release name>' in their repo
+- Support phases
+
++------------+-----------------------------+---------------------------------+
+|   Phase    |  Time Frame                 |  Changes Supported              |
++============+=============================+=================================+
+| I          | First 6 months              | All appropriate bug fixes       |
++------------+-----------------------------+---------------------------------+
+| II         | 6 - 12 months after release | Only critical or security fixes |
++------------+-----------------------------+---------------------------------+
+| III        | More than 12 months         | Only security fixes accepted    |
++------------+-----------------------------+---------------------------------+
+
+
+Proposing fixes to Stable Branches
+==================================
+- Fixes to stable must first merge to master and all intermediate branches
+- Appropriate backports
+
+  - Low regression risk in stable branch
+  - Fixes a user visible problem
+  - Backport is self contained
+
+- Inappropriate backports
+
+  - Backports of new functionality
+  - Changes to external HTTP APIs
+  - Notification, DB Schema or incompatible config file changes
+
+Stable Branch Reviews
+=====================
+
+- Stable maintenance teams
+
+  - Each project has a subset of cores able to merge stable branch changes
+
+- Ensure that the stable branch policies are enforced
+- Ensure that backports are associated with the patch submitted to master