Andreas Jaeger 4cff2ab6d5 Use Sphinx 1.5 warning-is-error

With pbr 2.0 and Sphinx 1.5, the setting for treat sphinx warnings as
errors is setting warning-is-error in build_sphinx section. Migrate
the setting from the old warnerrors one.

Fix problems found:
* Duplicate labels (rename wrong faq entries, rename unused drivers
  entries)
* Add api/autoindex.rst as hidden to the index so that we do not get a
  warning. The modindex includes the same content, so no need to show
  this.
* Add releasenotes/index.rst, webapi/v1.rst, user-guide, and install-guide.rst
  to hidden index since they're not listed in index on purpose, so sphinx
  will not warn that they do not appear in a toc
* Add deploy/radosgw to index
* ignore app.add_directiv warning
* Fix reference to user-guide to use proper markup so that Sphinx knows
  the user-guide is referenced.

Change-Id: I00d249229d4d31ba36d4393d60847fdb1513a744

2017-03-08 08:22:24 +01:00

3.5 KiB

Raw Blame History

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.

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.

Release process

Releases are managed by the OpenStack release team. The release process is documented in the Project Team Guide.

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).
For ironic releases only, not ironic-inspector releases: if any new API microversions have been added since the last release, update the REST API version history (doc/source/dev/webapi-version-history.rst) to indicate that they were part of the new release.
Set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that unsupported API tempest tests are skipped on stable branches.

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.

Additionally, changes need to be made on master to:

create an empty commit with a Sem-Ver tag to bump the generated minor version. See example and pbr documentation for details.

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.

3.5 KiB Raw Blame History