openstack/neutron
Code Issues Proposed changes

stadium: remove neutron-release from release job for stadium projects

Browse Source 
Now that release folks automated release process for independent
projects, we should be safe to offload the whole release management
process to openstack/releases machinery. Actually, leaving it up to
neutron-release team is error prone (f.e. we made mistakes before with
missing information in pushed git tags that held off email
announcements).

The idea of the change comes from Doug Hellmann. Quoting:

(in reference to no announcement email for networking-sfc 2.0.0)
> the email was skipped because you tagged the release by hand and the
> script didn't have the metadata it needed [...]
> this is why I want you to let us tag the releases.

Change-Id: Idc7f85fa860b3699d457ba00e800208acecb15de
This commit is contained in:
Ihar Hrachyshka
2016-09-09 00:54:16 +00:00
committed by Dariusz Smigiel
parent 65757a38ec
commit 053448dadd
1 changed files with 8 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
doc/source/stadium/guidelines.rst
View File

@@ -132,16 +132,15 @@ consumers of your code easier.
Sub-Project Release Process Sub-Project Release Process
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Only members of the `neutron-release All subproject releases are managed by `global OpenStack Release Managers team
<https://review.openstack.org/#/admin/groups/150,members>`_ gerrit group can do <https://review.openstack.org/#/admin/groups/11,members>`_. The
the following release related tasks: `neutron-release team
<https://review.openstack.org/#/admin/groups/150,members>`_ handles only the
following operations:
* Make releases
* Create stable branches * Create stable branches
* Make stable branches end of life * Make stable branches end of life
Make sure you talk to a member of neutron-release to perform these tasks.
To release a sub-project, follow the following steps: To release a sub-project, follow the following steps:
* For projects which have not moved to post-versioning, we need to push an * For projects which have not moved to post-versioning, we need to push an
@@ -155,19 +154,12 @@ To release a sub-project, follow the following steps:
<https://git.openstack.org/cgit/openstack/releases/tree/README.rst>`_ a patch <https://git.openstack.org/cgit/openstack/releases/tree/README.rst>`_ a patch
to openstack/releases repository with the intended git hash. `The Neutron to openstack/releases repository with the intended git hash. `The Neutron
release liaison <https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management>`_ release liaison <https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management>`_
should be added in Gerrit to the list of reviewers for the patch. should be added in Gerrit to the list of reviewers for the patch. Note: new
* If the subproject is not `managed major tag versions should conform to `SemVer <http://semver.org/>`_
<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 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 switch to SemVer is advised at earliest convenience for all new major
releases. releases.
* The Neutron release liaison votes with +1 for the openstack/releases patch * 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 * The releases will now be on PyPI. A sub-project owner should verify this by
going to an URL similar to going to an URL similar to
`this <https://pypi.python.org/simple/networking-odl>`_. `this <https://pypi.python.org/simple/networking-odl>`_.