openstack/ironic
Code Issues Proposed changes

Merge "Add docs about releasing ironic projects"

Browse Source
This commit is contained in:
Jenkins 2016-10-13 15:02:16 +00:00 committed by Gerrit Code Review
commit 70aebd668e
2 changed files with 82 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
doc/source/dev/releasing.rst Normal file
View File

@ -0,0 +1,74 @@
.. _faq:
=========================
Releasing Ironic Projects
=========================
Since the responsibility for releases will move between people, we document
that process here.
A full list of projects that ironic manages is available in the `governance
site`_.
.. _`governance site`: http://governance.openstack.org/reference/projects/ironic.html
Who is responsible for releases?
================================
The current PTL is ultimately responsible for making sure code gets released.
They may choose to delegate this reponsibility to a liaison, which is
documented in the `cross-project liaison wiki`_.
Anyone may submit a release request per the process below, but the PTL or
liaison must +1 the request for it to be processed.
.. _`cross-project liaison wiki`: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
Release process
===============
Releases are managed by the OpenStack release team. The release process is
documented in the `Project Team Guide`_.
.. _`Project Team Guide`: http://docs.openstack.org/project-team-guide/release-management.html#how-to-release
Things to do before releasing
=============================
Review the unreleased release notes, if the project uses them. Make sure
they follow our `standards`_, are coherent, and have proper grammar. Combine
release notes if necessary (for example, a release note for a feature and
another release note to add to that feature may be combined).
.. _`standards`: http://docs.openstack.org/developer/ironic/dev/faq.html#know-if-a-release-note-is-needed-for-my-change
Things to do after releasing
============================
When a release is done that results in a stable branch for the project, the
release automation will push a number of changes that need to be approved.
In the new stable branch, this will include:
* a change to point .gitreview at the branch
* a change to update the upper constraints file used by tox
In the master branch, this will include:
* updating the release notes RST to include the new branch
Additionally, changes need to be made to the stable branch to:
* update the ironic devstack plugin to point at the branched tarball for IPA.
An example of this patch is
`here <https://review.openstack.org/#/c/374863/>`_.
* update links in developer documentation to point to the branched version
of the install guide.
* update links in the install guide to point to the branched version of
the developer documentation.
For all releases, whether or not it results in a stable branch:
* update the specs repo to mark any specs completed in the release as
implemented.
* remove any -2s on patches that were blocked until after the release.

8
doc/source/index.rst
View File

@ -78,6 +78,14 @@ primarily for developers.
Provisioning State Machine <dev/states>
Notifications <dev/notifications>
These pages contain information for PTLs, cross-project liaisons, and core
reviewers.
.. toctree::
:maxdepth: 1
Releasing Ironic Projects <dev/releasing>
Writing Drivers
---------------