stadium: adopt openstack/releases in subproject release process

The openstack/releases repository is open for all official deliverables
(including stable releases for previous cycles), not just
release-with-milestone ones, and we are expected to update the repo in
addition to pushing signed git tags.

http://lists.openstack.org/pipermail/openstack-dev/2016-May/095225.html

With that, streamlined the release request process to avoid Launchpad
from the release scheme: new release requests are tracked and managed in
gerrit only. A new request now starts with a patch for
openstack/releases that should be handled by neutron-release team
members and approved by release liaison before merged by global
OpenStack release team.

Branch creation/expiration is still funneled through LP.

While at it, also suggest switching version numbering to SemVer at
earliest convenience.

Change-Id: Ifcae4b596bc27f7fc8a315e3807144ea03fbb83c

doc/source/policies/bugs.rst

@@ -135,29 +135,8 @@ It's also worth adding that some of these projects are part of the so
 called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
 Because of that, their release is managed centrally by the Neutron
 release team; requests for releases need to be funnelled and screened
-properly before they can happen. To this aim, the process to request a release
+properly before they can happen. Release request process is described `here
-is as follows:
+<http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process>`_.
-
-* Create a bug report to your Launchpad project: provide details as to what
-  you would like to release;
-
-  * If you provide an exact commit in the bug report then you need to be a bit
-    careful.  In most cases, you'll want to tag the *merge* commit that merges
-    your last commit in to the branch.  `This bug`__ shows an instance where
-    this mistake was caught.  Notice the difference between the `incorrect
-    commit`__ and the `correct one`__ which is the merge commit.  ``git log
-    6191994..22dd683 --oneline`` shows that the first one misses a handful of
-    important commits that the second one catches.  This is the nature of
-    merging to master.
-
-.. __: https://bugs.launchpad.net/neutron/+bug/1540633
-.. __: https://github.com/openstack/networking-infoblox/commit/6191994515
-.. __: https://github.com/openstack/networking-infoblox/commit/22dd683e1a
-
-* Add Neutron to the list of affected projects.
-* Add 'release-subproject' tag to the list of tags for the bug report.
-* The Neutron release management team will watch these bugs, and work with
-  you to have the request fulfilled by following the instructions found `here <http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#sub-project-release-process>`_.
 
 
 .. _guidelines:
@@ -428,7 +407,7 @@ more will be added over time if needed.
 +-------------------------------+-----------------------------------------+----------------------+
 | qos_                          | A bug affecting ML2/QoS                 | Miguel Ajo           |
 +-------------------------------+-----------------------------------------+----------------------+
-| release-subproject_           | A request to release a subproject       | Ihar Hrachyshka      |
+| release_                      | A request from a subproject             | Ihar Hrachyshka      |
 +-------------------------------+-----------------------------------------+----------------------+
 | rfe_                          | Feature enhancements being screened     | Drivers Team         |
 +-------------------------------+-----------------------------------------+----------------------+
@@ -713,13 +692,13 @@ QoS
 * `QoS - All bugs <https://bugs.launchpad.net/neutron/+bugs?field.tag=qos>`_
 * `QoS - In progress <https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=INPROGRESS&field.tag=qos>`_
 
-.. _release-subproject:
+.. _release:
 
-Release Subproject
+Requests from Stadium Subprojects
-++++++++++++++++++
++++++++++++++++++++++++++++++++++
 
-* `Release Subproject - All bugs <https://bugs.launchpad.net/neutron/+bugs?field.tag=release-subproject>`_
+* `Requests from Stadium Subprojects - All bugs <https://bugs.launchpad.net/neutron/+bugs?field.tag=release>`_
-* `Release Subproject - In progress <https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=INPROGRESS&field.tag=release-subproject>`_
+* `Requests from Stadium Subprojects - In progress <https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=INPROGRESS&field.tag=release>`_
 
 .. _rfe:
 

doc/source/stadium/sub_project_guidelines.rst

@@ -148,9 +148,6 @@ the following release related tasks:
 
 Make sure you talk to a member of neutron-release to perform these tasks.
 
-Follow the process found `here <http://docs.openstack.org/developer/neutron/policies/bugs.html#plugin-and-driver-repositories>`_
-for creating a bug for your request.
-
 To release a sub-project, follow the following steps:
 
 * For projects which have not moved to post-versioning, we need to push an
@@ -160,9 +157,23 @@ To release a sub-project, follow the following steps:
   have one), which moves your project to post-versioning, similar to all the
   other Neutron projects. You can skip this step if you don't have a version in
   setup.cfg.
-* A member of neutron-release will then `tag the release
+* A sub-project owner `proposes
-  <http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release>`_,
+  <https://git.openstack.org/cgit/openstack/releases/tree/README.rst>`_ a patch
-  which will release the code to PyPI.
+  to openstack/releases repository with the intended git hash. `The Neutron
+  release liaison <https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management>`_
+  should be added in Gerrit to the list of reviewers for the patch.
+* If the subproject is not `managed
+  <https://governance.openstack.org/reference/tags/release_managed.html>`_ by
+  OpenStack Release Team, a member of `neutron-release
+  <https://review.openstack.org/#/admin/groups/150,members>`_ `tags the release
+  <http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release>`_ and
+  creates the needed stable branches, if needed.  Note: tagging will release
+  the code to PyPI. Note: new major tag versions should conform to SemVer
+  requirements, meaning no year numbers should be used as a major version. The
+  switch to SemVer is advised at earliest convenience for all new major
+  releases.
+* The Neutron release liaison votes with +1 for the openstack/releases patch
+  that gives indication to release team the patch is ready to merge.
 * The releases will now be on PyPI. A sub-project owner should verify this by
   going to an URL similar to
   `this <https://pypi.python.org/pypi/networking-odl>`_.
@@ -179,6 +190,21 @@ To release a sub-project, follow the following steps:
 * Finally a sub-project owner should send an email to the openstack-announce
   mailing list announcing the new release.
 
+.. note::
+
+    You need to be careful when picking a git commit to base new releases on.
+    In most cases, you'll want to tag the *merge* commit that merges your last
+    commit in to the branch.  `This bug`__ shows an instance where this mistake
+    was caught.  Notice the difference between the `incorrect commit`__ and the
+    `correct one`__ which is the merge commit.  ``git log 6191994..22dd683
+    --oneline`` shows that the first one misses a handful of important commits
+    that the second one catches.  This is the nature of merging to master.
+
+.. __: https://bugs.launchpad.net/neutron/+bug/1540633
+.. __: https://github.com/openstack/networking-infoblox/commit/6191994515
+.. __: https://github.com/openstack/networking-infoblox/commit/22dd683e1a
+
+
 To make a branch end of life, follow the following steps:
 
 * A member of neutron-release will abandon all open change reviews on