From 4852772744e50b2567472906577c7d42606cba93 Mon Sep 17 00:00:00 2001 From: Jim Rollenhagen Date: Wed, 12 Oct 2016 20:54:44 +0000 Subject: [PATCH] Add docs about releasing ironic projects Provides links and details about things to do when releasing a project in the ironic umbrella. Change-Id: I498c29f74ee9b10676157b7d74aaab288f94e301 --- doc/source/dev/releasing.rst | 74 ++++++++++++++++++++++++++++++++++++ doc/source/index.rst | 8 ++++ 2 files changed, 82 insertions(+) create mode 100644 doc/source/dev/releasing.rst diff --git a/doc/source/dev/releasing.rst b/doc/source/dev/releasing.rst new file mode 100644 index 0000000000..789b1d1d99 --- /dev/null +++ b/doc/source/dev/releasing.rst @@ -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 `_. + * 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. diff --git a/doc/source/index.rst b/doc/source/index.rst index 38a43635ae..74e5cfdb81 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -78,6 +78,14 @@ primarily for developers. Provisioning State Machine Notifications +These pages contain information for PTLs, cross-project liaisons, and core +reviewers. + +.. toctree:: + :maxdepth: 1 + + Releasing Ironic Projects + Writing Drivers ---------------