openstack/neutron
Code Issues Proposed changes

stadium: adopt openstack/releases in subproject release process

Browse Source 
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
This commit is contained in:
Ihar Hrachyshka 2016-04-21 15:23:55 +02:00
parent 7cff2287bb
commit 4ff721590e
2 changed files with 40 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/source/policies/bugs.rst
View File

@ -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
is as follows:
* 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>`_.
properly before they can happen. Release request process is described `here
<http://docs.openstack.org/developer/neutron/stadium/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>`_
* `Release Subproject - In progress <https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=INPROGRESS&field.tag=release-subproject>`_
* `Requests from Stadium Subprojects - All bugs <https://bugs.launchpad.net/neutron/+bugs?field.tag=release>`_
* `Requests from Stadium Subprojects - In progress <https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=INPROGRESS&field.tag=release>`_
.. _rfe:

38
doc/source/stadium/sub_project_guidelines.rst
View File

@ -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
<http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release>`_,
which will release the code to PyPI.
* A sub-project owner `proposes
<https://git.openstack.org/cgit/openstack/releases/tree/README.rst>`_ a patch
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