doc: move the release cycle after the timeline

The timeline is a useful reference and the reader should not have to
scroll down to see it. Move the release cycle after the timeline.

Signed-off-by: Loic Dachary <ldachary@redhat.com>

diff --git a/doc/releases.rst b/doc/releases.rst
index d3c330612557954f383c8d1fab4f7d24b5c6d921..eddce43a0c70dd73b447985fa63f4be750ae9a6a 100644 (file)
--- a/doc/releases.rst
+++ b/doc/releases.rst
@@ -1,59 +1,9 @@
-================
-Release timeline
-================
+=============
+Ceph Releases
+=============
 
-The development release cycle is two to four weeks long.  Each cycle
-freezes the master development branch and applies `integration and
-upgrade tests <https://github.com/ceph/ceph-qa-suite>`_ for the
-duration of one cycle before it is released and the next release's
-code is frozen for testing.  Once released, there is no effort to
-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
-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
-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
-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
-* Stable release : until the next stable release is published
-* Development / testing release : no backports
-
-For each stable release:
-
-* `Integration and upgrade tests
-  <https://github.com/ceph/ceph-qa-suite>`_ are run on a regular basis
-  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
-  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.
-
-In the following, the life time of a LTS is calculated to be
-approximately 18 months after the month of the first release. For
-instance, Dumpling is published August 2013 and 18 months starting
-September 2013 is February 2015, therefore by March 2015 Dumpling
-should be retired. The lifetime of a release may vary because it
-depend on how quickly the stable releases are published. For instance
-although Dumpling theoritical retirement was March 2015, it was
-extended to May 2015.
+Timeline
+--------
 
 +----------------------------+-----------+-----------+-----------+-----------+-----------+
 |                            |`Dumpling`_|`Emperor`_ |`Firefly`_ |`Giant`_   |`Hammer`_  |
@@ -220,3 +170,59 @@ extended to May 2015.
 .. _0.67.1: ../release-notes#v0-67-1-dumpling
 .. _0.67: ../release-notes#v0-67-dumpling
 .. _Dumpling:  ../release-notes#v0-67-dumpling
+
+Understanding the release cycle
+-------------------------------
+
+The development release cycle is two to four weeks long.  Each cycle
+freezes the master development branch and applies `integration and
+upgrade tests <https://github.com/ceph/ceph-qa-suite>`_ for the
+duration of one cycle before it is released and the next release's
+code is frozen for testing.  Once released, there is no effort to
+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
+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
+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
+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
+* Stable release : until the next stable release is published
+* Development / testing release : no backports
+
+For each stable release:
+
+* `Integration and upgrade tests
+  <https://github.com/ceph/ceph-qa-suite>`_ are run on a regular basis
+  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
+  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.
+
+In the timeline, the life time of a LTS is calculated to be
+approximately 18 months after the month of the first release. For
+instance, Dumpling is published August 2013 and 18 months starting
+September 2013 is February 2015, therefore by March 2015 Dumpling
+should be retired. The lifetime of a release may vary because it
+depend on how quickly the stable releases are published. For instance
+although Dumpling theoritical retirement was March 2015, it was
+extended to May 2015.