Merge pull request #8358 from dachary/wip-releases

releases: what is merged where and when ?

Reviewed-by: Josh Durgin <jdurgin@redhat.com>
Reviewed-by: Nathan Cutler <ncutler@suse.cz>
Reviewed-by: Sage Weil <sage@redhat.com>

doc/dev/index.rst

@@ -179,6 +179,145 @@ with::
 
 For more ``vstart.sh`` examples, see :doc:`/dev/quick_guide`.
 
+What is merged where and when ?
+===============================
+
+Commits are merged into branches according to criteria that change
+during the lifecycle of a Ceph release. This chapter is the inventory
+of what can be merged in which branch at a given point in time.
+
+Development releases (i.e. x.0.z)
+---------------------------------
+
+What ?
+^^^^^^
+
+* features
+* bug fixes
+
+Where ?
+^^^^^^^
+
+Features are merged to the master branch. Bug fixes should be merged
+to the corresponding named branch (e.g. "jewel" for 10.0.z, "kraken"
+for 11.0.z, etc.). However, this is not mandatory - bug fixes can be
+merged to the master branch as well, since the master branch is
+periodically merged to the named branch during the development
+releases phase. In either case, if the bugfix is important it can also
+be flagged for backport to one or more previous stable releases.
+
+When ?
+^^^^^^
+
+After the stable release candidates of the previous release enters
+phase 2 (see below).  For example: the "jewel" named branch was
+created when the infernalis release candidates entered phase 2. From
+this point on, master was no longer associated with infernalis. As
+soon as the named branch of the next stable release is created, master
+starts getting periodically merged into it.
+
+Branch merges
+^^^^^^^^^^^^^
+
+* The branch of the stable release is merged periodically into master.
+* The master branch is merged periodically into the branch of the
+  stable release.
+* The master is merged into the branch of the stable release
+  immediately after each development x.0.z release.
+
+Stable release candidates (i.e. x.1.z) phase 1
+----------------------------------------------
+
+What ?
+^^^^^^
+
+* bug fixes only
+
+Where ?
+^^^^^^^
+
+The branch of the stable release (e.g. "jewel" for 10.0.z, "kraken"
+for 11.0.z, etc.) or master.  Bug fixes should be merged to the named
+branch corresponding to the stable release candidate (e.g. "jewel" for
+10.1.z) or to master. During this phase, all commits to master will be
+merged to the named branch, and vice versa. In other words, it makes
+no difference whether a commit is merged to the named branch or to
+master - it will make it into the next release candidate either way.
+
+When ?
+^^^^^^
+
+After the first stable release candidate is published, i.e. after the
+x.1.0 tag is set in the release branch.
+
+Branch merges
+^^^^^^^^^^^^^
+
+* The branch of the stable release is merged periodically into master.
+* The master branch is merged periodically into the branch of the
+  stable release.
+* The master is merged into the branch of the stable release
+  immediately after each x.1.z release candidate.
+
+Stable release candidates (i.e. x.1.z) phase 2
+----------------------------------------------
+
+What ?
+^^^^^^
+
+* bug fixes only
+
+Where ?
+^^^^^^^
+
+The branch of the stable release (e.g. "jewel" for 10.0.z, "kraken"
+for 11.0.z, etc.). During this phase, all commits to the named branch
+will be merged into master. Cherry-picking to the named branch during
+release candidate phase 2 is done manually since the official
+backporting process only begins when the release is pronounced
+"stable".
+
+When ?
+^^^^^^
+
+After Sage Weil decides it is time for phase 2 to happen.
+
+Branch merges
+^^^^^^^^^^^^^
+
+* The branch of the stable release is merged periodically into master.
+
+Stable releases (i.e. x.2.z)
+----------------------------
+
+What ?
+^^^^^^
+
+* bug fixes
+* features are sometime accepted
+* commits should be cherry-picked from master when possible
+* commits that are not cherry-picked from master must be about a bug unique to the stable release
+* see also `the backport HOWTO`_
+
+.. _`the backport HOWTO`:
+  http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO#HOWTO
+
+Where ?
+^^^^^^^
+
+The branch of the stable release (hammer for 0.94.x, infernalis for 9.2.x, etc.)
+
+When ?
+^^^^^^
+
+After the stable release is published, i.e. after the "vx.2.0" tag is
+set in the release branch.
+
+Branch merges
+^^^^^^^^^^^^^
+
+Never
+
 Issue tracker
 =============
 

doc/release-notes.rst

@@ -1942,10 +1942,15 @@ Notable Changes since Hammer
 * upstart: throttle restarts (#11798 Sage Weil, Greg Farnum)
 
 
+v10.0.5
+=======
+
+This is identical to v10.0.4 and was only created because of a git tagging mistake.
+
 v10.0.4
 =======
 
-This is the fourth and last development release before Jewel.  The next release
+This is the fifth and last development release before Jewel.  The next release
 will be a release candidate with the final set of features.  Big items include
 RGW static website support, librbd journal framework, fixed mon sync of config-key
 data, C++11 updates, and bluestore/kstore.

doc/releases.rst

@@ -24,7 +24,7 @@ Timeline
 |                |Testing    |LTS        |Stable     |LTS        |Stable     |LTS        |Stable        |
 +----------------+-----------+-----------+-----------+-----------+-----------+-----------+--------------+
 | March     2016 |`10.1.0`_  |           |           |           |           |           |              |
-|                |`10.0.4`_  |           |           |           |           |           |              |
+|                |`10.0.5`_  |           |           |           |           |           |              |
 +----------------+-----------+-----------+-----------+-----------+-----------+-----------+--------------+
 | February  2016 |`10.0.3`_  |           |           |           |           |`0.94.6`_  |`9.2.1`_      |
 +----------------+-----------+-----------+-----------+-----------+-----------+-----------+--------------+
@@ -123,7 +123,7 @@ Timeline
 |                |           |`0.67`_    |           |           |           |           |              |
 +----------------+-----------+-----------+-----------+-----------+-----------+-----------+--------------+
 
-.. _10.0.4: ../release-notes#v10-0-4
+.. _10.0.5: ../release-notes#v10-0-5
 .. _10.0.3: ../release-notes#v10-0-3
 .. _10.0.2: ../release-notes#v10-0-2
 .. _10.0.1: ../release-notes#v10-0-1
@@ -225,23 +225,23 @@ backport fixes; developer focus in on the next development release
 which is usually only a few weeks away.
 
 There are three to four stable releases a year.  Each stable release
-will receive a name (e.g., 'Firefly') and bug fix backports at least
+will receive a name (e.g., 'Jewel') and bug fix backports at least
 until the next stable release is out.
 
 Every other stable releases is a LTS (Long Term Stable) and will
 receive updates until two LTS are published. For instance Dumpling is
 retired when Hammer is published, Firefly is retired when Jewel is
-published etc. The rationale is that backports to a LTS (Dumpling for
+published etc. The rationale is that backports to a LTS (Firefly for
 instance) are expected to happen until the next LTS is published
-(Firefly is the LTS following Dumpling), to fix bugs and possibly
-backport important features. After the next LTS is published, there
+(Jewel is the LTS following Hammer), to fix bugs and possibly
+backport important features. After the next LTS is published,
 backports are still expected to fix bugs with a focus on whatever can
 prevent upgrades to the next LTS (in our example, fixes to Dumpling
 were published after Firefly was released and until Hammer was
 published, primarily to ensure Dumpling cluster can smoothly migrate
 to Firefly).
 
-* LTS : until the next two LTS are published
+* Long Term Stable : until the next two LTS are published
 * Stable release : until the next stable release is published
 * Development / testing release : no backports
 
@@ -252,13 +252,12 @@ For each stable release:
   and `their results <http://pulpito.ceph.com/>`_ analyzed by Ceph
   developers.
 * `Issues <http://tracker.ceph.com/projects/ceph/issues?query_id=27>`_
-  fixed in the development branch is scheduled to be backported to the
-  release.
-* When an issue found in the release is `reported
-  <http://tracker.ceph.com/projects/ceph/issues/new>`_ it will be
+  fixed in the development branch (master) are scheduled to be backported.
+* When an issue found in the stable release is `reported
+  <http://tracker.ceph.com/projects/ceph/issues/new>`_, it is
   triaged by Ceph developers.
 * The `stable releases and backport team <http://tracker.ceph.com/projects/ceph-releases>`_
-  publishes ``point releases`` including fixes that have been backported to the release.
+  publishes ``point releases`` including fixes that have been backported to the stable release.
 
 In the timeline, the life time of a LTS is calculated to be
 approximately 18 months after the month of the first release. For