From 5b56cbe8c354e3e2cbee4f22130e509cbf01528d Mon Sep 17 00:00:00 2001 From: Jay Faulkner Date: Thu, 26 Jan 2023 11:32:35 -0800 Subject: [PATCH] Minor spelling/grammar fixes for release docs Fix spelling, make Ironic capitalized throughout. Change-Id: Ia689954279034d21c60dea4bca73ee5b1bb41d81 --- doc/source/contributor/releasing.rst | 34 ++++++++++++++-------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/source/contributor/releasing.rst b/doc/source/contributor/releasing.rst index 3c0732c5b8..a83bdc2bd2 100644 --- a/doc/source/contributor/releasing.rst +++ b/doc/source/contributor/releasing.rst @@ -5,7 +5,7 @@ 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 +A full list of projects that Ironic manages is available in the `governance site`_. .. _`governance site`: https://governance.openstack.org/reference/projects/ironic.html @@ -33,7 +33,7 @@ documented in the `Project Team Guide`_. What do we have to release? =========================== -The ironic project has a number of deliverables under its governance. The +The Ironic project has a number of deliverables under its governance. The ultimate source of truth for this is `projects.yaml `__ in the governance repository. These deliverables have varying release models, @@ -41,7 +41,7 @@ and these are defined in the `deliverables YAML files `__ in the releases repository. -In general, ironic deliverables follow the `cycle-with-intermediary +In general, Ironic deliverables follow the `cycle-with-intermediary `__ release model. @@ -130,7 +130,7 @@ OpenStack release that happens semi-annually. These releases can be found in a ``stable/NAME`` branch. They are also evaluated for additional bugfix releases between scheduled -stable releases at the two and four month milestore between stable releases +stable releases at the two and four month milestone between stable releases (roughly every 2 months). These releases can be found in a ``bugfix/X.Y`` branch. A bugfix release is only created if there are significant beneficial changes and a known downstream operator or distributor will consume @@ -143,12 +143,12 @@ version. Currently releases and retirements from bugfix branches cannot be automated and must be done by the release team manually. -After the creation of a bugfix branch it is utmost important to update the -upper-constraints link for the tests in the tox.ini file, plus override the -branch for the requirements project to be sure to use the correct +After the creation of a bugfix branch it is of the utmost importance to update +the upper-constraints link for the tests in the tox.ini file, plus override +the branch for the requirements project to be sure to use the correct upper-constraints; for example see the following change: -https://review.opendev.org/c/openstack/ironic-python-agent/+/841290 +https://review.opendev.org/c/openstack/Ironic-python-agent/+/841290 Things to do before releasing ============================= @@ -159,7 +159,7 @@ Things to do before releasing 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 +* 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/contributor/webapi-version-history.rst``) to indicate that they were part of the new release. @@ -200,7 +200,7 @@ following the next steps: deliverable (i.e. subproject) grouped by release cycles. * The ``_independent`` directory contains yaml files for deliverables that - are not bound to (official) cycles (e.g. ironic-python-agent-builder). + are not bound to (official) cycles (e.g. Ironic-python-agent-builder). * To check the changes we're about to release we can use the tox environment ``list-unreleased-changes``, with this syntax: @@ -213,7 +213,7 @@ following the next steps: not stable/ussuri or stable/train). For example, assuming we're in the main directory of the releases repository, - to check the changes in the ussuri series for ironic-python-agent + to check the changes in the ussuri series for Ironic-python-agent type: .. code-block:: bash @@ -243,12 +243,12 @@ following the next steps: The ``--intermediate-branch`` option is used to create an intermediate bugfix branch following the - `new release model for ironic projects `_. + `new release model for Ironic projects `_. To propose the release, use the script to update the deliverable file, then commit the change, and propose it for review. - For example, to propose a minor release for ironic in the master branch + For example, to propose a minor release for Ironic in the master branch (current development branch), considering that the code name of the future stable release is wallaby, use: @@ -260,7 +260,7 @@ following the next steps: deliverable, the new version and the branch, if applicable. A good commit message title should also include the same, for example - "Release ironic 1.2.3 for ussuri" + "Release Ironic 1.2.3 for ussuri" * As an optional step, we can use ``tox -e list-changes`` to double-check the changes before submitting them for review. @@ -310,7 +310,7 @@ This includes: We need to submit patches for changes in the stable branch to: -* update the ironic devstack plugin to point at the branched tarball for IPA. +* update the Ironic devstack plugin to point at the branched tarball for IPA. An example of this patch is `here `_. * set appropriate defaults for ``TEMPEST_BAREMETAL_MIN_MICROVERSION`` and @@ -324,7 +324,7 @@ We need to submit patches for changes on master to: need to make these changes. Note that we need to wait until *after* the switch in grenade is made to test the latest release (N) with master (e.g. `for stable/queens `_). - Doing these changes sooner -- after the ironic release and before the switch + Doing these changes sooner -- after the Ironic release and before the switch when grenade is testing the prior release (N-1) with master, will cause the tests to fail. (You may want to ask/remind infra/qa team, as to when they will do this switch.) @@ -335,7 +335,7 @@ We need to submit patches for changes on master to: only support upgrades from the most recent named release to master. * remove any DB migration scripts from ``ironic.cmd.dbsync.ONLINE_MIGRATIONS`` - and remove the corresponding code from ironic. (These migration scripts + and remove the corresponding code from Ironic. (These migration scripts are used to migrate from an old release to this latest release; they shouldn't be needed after that.)