Added initial release check list

The document is hopefully a good start and will eventually collect
enough information and tips for next release managers to run the
nervous process more smoothly.

Change-Id: Iaa14d818ae13e7cfa5ad061a2ae9d87a1f0fd331

doc/source/policies/index.rst

@@ -30,4 +30,5 @@ items.
    neutron-teams
    gate-failure-triage
    code-reviews
+   release-checklist
    thirdparty-ci

doc/source/policies/release-checklist.rst

@@ -0,0 +1,121 @@
+Pre-release check list
+======================
+
+This page lists things to cover before a Neutron release and will serve as a
+guide for next release managers.
+
+Server
+------
+
+Major release
+~~~~~~~~~~~~~
+
+Major release is cut off once per development cycle and has an assigned name
+(Liberty, Mitaka, ...)
+
+Prior to major release,
+
+#. consider blocking all patches that are not targeted for the new release;
+#. consider blocking trivial patches to keep the gate clean;
+#. revise the current list of blueprints and bugs targeted for the release;
+   roll over anything that does not fit there, or won't make it (note that no
+   new features land master after so called feature freeze is claimed by
+   release team; there is a feature freeze exception (FFE) process described in
+   release engineering documentation in more details:
+   http://docs.openstack.org/project-team-guide/release-management.html);
+#. start collecting state for targeted features from the team. For example,
+   propose a postmortem patch for neutron-specs as in:
+   https://review.openstack.org/#/c/286413/
+#. revise deprecation warnings collected in latest Jenkins runs: some of them
+   may indicate a problem that should be fixed prior to release (see
+   deprecations.txt file in those log directories); also, check whether any
+   Launchpad bugs with the 'deprecation' tag need a clean-up or a follow-up in
+   the context of the release planned;
+#. check that release notes and sample configuration files render correctly,
+   arrange clean-up if needed.
+
+New major release process contains several phases:
+
+#. master branch is blocked for patches that are not targeted for the release;
+#. the whole team is expected to work on closing remaining pieces targeted for
+   the release;
+#. once the team is ready to release the first release candidate (RC1), either
+   PTL or one of release liaisons proposes a patch for openstack/releases repo.
+   For example, see: https://review.openstack.org/#/c/292445/
+#. once the openstack/releases patch land, release team creates a new stable
+   branch using hash values specified in the patch;
+#. at this point, master branch is open for patches targeted to the next
+   release; PTL unblocks all patches that were blocked in step 1;
+#. if additional patches are identified that are critical for the release and
+   must be shipped in the final major build, correpsponding bugs are tagged
+   with <release>-rc-potential in Launchpad, fixes are prepared and land in
+   master branch, and are then backported to the newly created stable branch;
+#. if patches landed in the release stable branch as per the previous step, a
+   new release candidate that would include those patches should be requested
+   by PTL in openstack/releases repo.
+#. eventually, the latest release candidate requested by PTL becomes the final
+   major release of the project.
+
+Release candidate (RC) process allows for stabilization of the final release.
+
+The following technical steps should be taken before the final release is cut
+off:
+
+#. the latest alembic scripts are tagged with a milestone label. For example,
+   see: https://review.openstack.org/#/c/288212/
+
+In the new stable branch, you should make sure that:
+
+#. .gitreview file points to the new branch;
+#. if the branch uses constraints to manage gated dependency versions, the
+   default constraints file name points to corresponding stable branch in
+   openstack/requirements repo;
+#. if the branch fetches any other projects as dependencies, f.e. by using
+   tox_install.sh as an install_command in tox.ini, git repository links point
+   to corresponding stable branches of those dependency projects.
+
+Note that some of those steps may be covered by OpenStack release team.
+
+In the opened master branch, you should:
+
+#. update CURRENT_RELEASE in neutron.db.migration.cli to point to the next
+   release name.
+
+While preparing the next release and even in the middle of development, it's
+worth keeping the infrastructure clean. Consider using those tools to declutter
+the project infrastructure:
+
+#. declutter Gerrit::
+
+    <neutron>/tools/abandon_old_reviews.sh
+
+#. declutter Launchpad::
+
+    <release-tools>/pre_expire_bugs.py neutron --day <back-to-the-beginning-of-the-release>
+
+
+Minor release
+~~~~~~~~~~~~~
+
+Minor release is a release created from existing stable branch after the
+initial major release, and that usually contains bug fixes and small
+improvements only.
+
+The following steps should be taken before claiming a successful minor release:
+
+#. a patch for openstack/releases repo is proposed and merged.
+
+
+Client
+------
+
+Most tips from the Server section apply to client releases too. Several things
+to note though:
+
+#. when preparing for a major release, pay special attention to client bits
+   that are targeted for the release. Global openstack/requirements freeze
+   happens long before first RC release of server components. So if you plan to
+   land server patches that depend on a new client, make sure you don't miss
+   the requirements freeze. After the freeze is in action, there is no easy way
+   to land more client patches for the planned target. All this may push an
+   affected feature to the next development cycle.