From 4ff721590e78b1d37482e537d61892e0e53c45ab Mon Sep 17 00:00:00 2001 From: Ihar Hrachyshka Date: Thu, 21 Apr 2016 15:23:55 +0200 Subject: [PATCH] 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 | 37 ++++-------------- doc/source/stadium/sub_project_guidelines.rst | 38 ++++++++++++++++--- 2 files changed, 40 insertions(+), 35 deletions(-) diff --git a/doc/source/policies/bugs.rst b/doc/source/policies/bugs.rst index 88bc0637867..58577a9c979 100644 --- a/doc/source/policies/bugs.rst +++ b/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 `_. 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 `_. +properly before they can happen. Release request process is described `here +`_. .. _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 `_ * `QoS - In progress `_ -.. _release-subproject: +.. _release: -Release Subproject -++++++++++++++++++ +Requests from Stadium Subprojects ++++++++++++++++++++++++++++++++++ -* `Release Subproject - All bugs `_ -* `Release Subproject - In progress `_ +* `Requests from Stadium Subprojects - All bugs `_ +* `Requests from Stadium Subprojects - In progress `_ .. _rfe: diff --git a/doc/source/stadium/sub_project_guidelines.rst b/doc/source/stadium/sub_project_guidelines.rst index 212671e82fd..445ec7ac61d 100644 --- a/doc/source/stadium/sub_project_guidelines.rst +++ b/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 `_ -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 - `_, - which will release the code to PyPI. +* A sub-project owner `proposes + `_ a patch + to openstack/releases repository with the intended git hash. `The Neutron + release liaison `_ + should be added in Gerrit to the list of reviewers for the patch. +* If the subproject is not `managed + `_ by + OpenStack Release Team, a member of `neutron-release + `_ `tags the 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 `_. @@ -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