Clarify release model choices

Further clarify why you would pick one release model or
the other (in particular mentioning that depends on how
much the team has internalized the release management
function).

Change-Id: I283de7cb1139bd45c5e6caf389be4a03e1a0a916

doc/source/release-management.rst

@@ -26,9 +26,10 @@ Common cycle with development milestones
 
 By default, most OpenStack services opt to follow a common, time-based
 release model. It results in a single release at the end of the development
-cycle. It is recommended at the earlier stages of development, when
+cycle, with a few milestones to mark the progress in between. It is
-it is difficult to commit to multiple upgrade paths and large features or
+recommended at the middle stages of development, when regular releases
-architectural refactors are still common.
+are desirable, but release management is not internalized in the team,
+and testing coverage is not perfect yet.
 
 Projects following that model use a pre-version numbering scheme. If the
 final release will be called 5.0.0, intermediary milestones will be called
@@ -98,16 +99,19 @@ Common cycle with intermediary releases
 
 Projects which want to do a formal release more often, but still want to
 coordinate a release at the end of the cycle from which to maintain a stable
-branch may opt for this model. This is especially suitable to libraries, and
+branch may opt for this model. All our libraries follow this model, in order
-to more stable projects which add a limited set of new features and don't plan
+to allow for immediate consumption of new features in consuming projects.
-to go through large architectural changes. Getting the latest and greatest out
+But this is also potentially suitable for regular projects, either at the
-as often as possible, while ensuring stability and upgradeability.
+very early stages (where releasing often can be useful) or once the project
+is more stable, changes are limited, automated testing can be relied on, and
+the team decided to more directly handle release management.
 
 Projects following this model do not use intermediary development milestones.
 They may request publication of versions at any point in time during the
 development cycle. They do not use Feature Freeze, they do not go through a
-release candidate cycle. They use a post-version semver-based numbering scheme,
+release candidate cycle. Every tag is a release supposed to be consumable by
-where every tag is a X.Y.Z version.
+users. They use a post-version semver-based numbering scheme, where every tag
+is a X.Y.Z version.
 
 Those projects must request a final version for a development cycle (generally
 in the last month of the cycle). A stable branch is cut from that proposed
@@ -253,9 +257,9 @@ must ensure they are done by someone on the project team.
 
    See :ref:`release-process-managed` above.
 
-#. Coordinate feature freeze exceptions (FFEs) at the end of a
+#. Coordinate feature freeze exceptions (FFEs) at the end of a release
-   release, and track blocking bug fixes and feature work that must be
+   cycle (for cycle-with-milestones deliverables), and track blocking
-   completed before a release.
+   bug fixes and feature work that must be completed before a release.
 
    The period between feature freeze and release should be used to
    stabilize new features and fix bugs. However, for every release
@@ -294,12 +298,12 @@ must ensure they are done by someone on the project team.
 Typical Development Cycle Schedule
 ==================================
 
-The development cycles follow a repeating pattern, which is described
+The development cycles for cycle-with-milestones deliverables follow a
-in general terms here. The length of time between milestones may
+repeating pattern, which is described in general terms here. The length
-change from cycle to cycle because of holidays, event scheduling, and
+of time between milestones may change from cycle to cycle because of
-other factors, so consult the wiki for the actual schedule for the
+holidays, event scheduling, and other factors, so consult the actual
-current cycle.  The cycles follow a repeating pattern, which is
+'Under development' schedule on the `releases website`_ for the actual
-described more generally here.
+schedule.
 
 Weeks with negative numbers are counting down leading to the event
 ("Release -2" is 2 weeks before the release). Weeks with positive
@@ -414,6 +418,7 @@ Release 0
   Thursday of this week
 - All library releases freeze on master ends
 
+.. _releases website: https://releases.openstack.org/
 
 Managing Release Notes
 ======================