diff --git a/doc/source/contributor/index.rst b/doc/source/contributor/index.rst index 7c591953e7dd..84c78255cf0b 100644 --- a/doc/source/contributor/index.rst +++ b/doc/source/contributor/index.rst @@ -42,6 +42,8 @@ while keeping users happy and keeping developers productive. * :doc:`/contributor/blueprints`: An overview of our tracking artifacts. +* :doc:`/contributor/ptl-guide`: A chronological PTL reference guide + Reviewing ========= diff --git a/doc/source/contributor/ptl-guide.rst b/doc/source/contributor/ptl-guide.rst new file mode 100644 index 000000000000..f5fa9305cfc5 --- /dev/null +++ b/doc/source/contributor/ptl-guide.rst @@ -0,0 +1,298 @@ +.. + Licensed under the Apache License, Version 2.0 (the "License"); you may + not use this file except in compliance with the License. You may obtain + a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + License for the specific language governing permissions and limitations + under the License. + +Chronological PTL guide +======================= + +This is just a reference guide that a PTL may use as an aid, if they choose. + +New PTL +------- + +* Update the nova meeting chair + + * https://github.com/openstack-infra/irc-meetings/blob/master/meetings/nova-team-meeting.yaml + +* Update the team wiki + + * https://wiki.openstack.org/wiki/Nova#People + +* Get acquainted with the release schedule + + * Example: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule + +Project Team Gathering +---------------------- + +* Create PTG planning etherpad, retrospective etherpad and alert about it in + nova meeting and dev mailing list + + * Example: https://etherpad.openstack.org/p/nova-ptg-stein + +* Run sessions at the PTG + +* Have a priorities discussion at the PTG + + * Example: https://etherpad.openstack.org/p/nova-ptg-stein-priorities + +* Sign up for group photo at the PTG (if applicable) + +* Open review runways for the cycle + + * Example: https://etherpad.openstack.org/p/nova-runways-stein + +After PTG +--------- + +* Send PTG session summaries to the dev mailing list + +* Make sure the cycle priorities spec gets reviewed and merged + + * Example: https://specs.openstack.org/openstack/nova-specs/priorities/stein-priorities.html + +* Run the count-blueprints script daily to gather data for the cycle burndown chart + +A few weeks before milestone 1 +------------------------------ + +* Plan a spec review day + +* Periodically check the series goals others have proposed in the “Set series + goals” link: + + * Example: https://blueprints.launchpad.net/nova/stein/+setgoals + +Milestone 1 +----------- + +* Do milestone release of nova and python-novaclient (in launchpad only) + + * This is launchpad bookkeeping only. With the latest release team changes, + projects no longer do milestone releases. See: https://releases.openstack.org/reference/release_models.html#cycle-with-milestones-legacy + + * For nova, set the launchpad milestone release as “released” with the date + +* Release other libraries if there are significant enough changes since last + release. When releasing the first version of a library for the cycle, bump + the minor version to leave room for future stable branch releases + + * os-vif + +* Release stable branches of nova + + * ``git checkout `` + + * ``git log --no-merges ..`` + + * Examine commits that will go into the release and use it to decide + whether the release is a major, minor, or revision bump according to + semver + + * Then, propose the release with version according to semver x.y.z + + * X - backward-incompatible changes + + * Y - features + + * Z - bug fixes + + * Use the new-release command to generate the release + + * https://releases.openstack.org/reference/using.html#using-new-release-command + +Summit +------ + +* Prepare the project update presentation. Enlist help of others + +* Prepare the on-boarding session materials. Enlist help of others + +A few weeks before milestone 2 +------------------------------ + +* Plan a spec review day (optional) + +* Periodically check the series goals others have proposed in the “Set series + goals” link: + + * Example: https://blueprints.launchpad.net/nova/stein/+setgoals + +Milestone 2 +----------- + +* Spec freeze + +* Release nova and python-novaclient + +* Release other libraries as needed + +* Stable branch releases of nova + +* For nova, set the launchpad milestone release as “released” with the date + +Shortly after spec freeze +------------------------- + +* Create a blueprint status etherpad to help track, especially non-priority + blueprint work, to help things get done by Feature Freeze (FF). Example: + + * https://etherpad.openstack.org/p/nova-stein-blueprint-status + +* Create or review a patch to add the next release’s specs directory so people + can propose specs for next release after spec freeze for current release + +Non-client library release freeze +--------------------------------- + +* Final release for os-vif + +Milestone 3 +----------- + +* Feature freeze day + +* Client library freeze, release python-novaclient + +* Close out all blueprints, including “catch all” blueprints like mox, + versioned notifications + +* Stable branch releases of nova + +* For nova, set the launchpad milestone release as “released” with the date + +Week following milestone 3 +-------------------------- + +* Consider announcing the FFE (feature freeze exception process) to have people + propose FFE requests to a special etherpad where they will be reviewed and + possibly sponsored: + + * https://docs.openstack.org/nova/latest/contributor/process.html#non-priority-feature-freeze + + * Note: if there is only a short time between FF and RC1 (lately it’s been 2 + weeks), then the only likely candidates will be low-risk things that are + almost done + +A few weeks before RC +--------------------- + +* Make a RC1 todos etherpad and tag bugs as ``-rc-potential`` and keep + track of them, example: + + * https://etherpad.openstack.org/p/nova-stein-rc-potential + +* Go through the bug list and identify any rc-potential bugs and tag them + +RC +-- + +* Do steps described on the release checklist wiki: + + * https://wiki.openstack.org/wiki/Nova/ReleaseChecklist + +* If we want to drop backward-compat RPC code, we have to do a major RPC + version bump and coordinate it just before the major release: + + * https://wiki.openstack.org/wiki/RpcMajorVersionUpdates + + * Example: https://review.openstack.org/541035 + +* “Merge latest translations" means translation patches + + * Check for translations with: + + * https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:zanata/translations + +* Should NOT plan to have more than one RC if possible. RC2 should only happen + if there was a mistake and something was missed for RC, or a new regression + was discovered + +* Do the RPC version aliases just before RC1 if no further RCs are planned. + Else do them at RC2. In the past, we used to update all service version + aliases (example: https://review.openstack.org/230132) but since we really + only support compute being backlevel/old during a rolling upgrade, we only + need to update the compute service alias, see related IRC discussion: + http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-08-08.log.html#t2018-08-08T17:13:45 + + * Example: https://review.openstack.org/642599 + + * More detail on how version aliases work: https://docs.openstack.org/nova/latest/configuration/config.html#upgrade-levels + +* Write the reno prelude for the release GA + + * Example: https://review.openstack.org/644412 + +* Write the cycle-highlights in marketing-friendly sentences and propose to the + openstack/releases repo. Usually based on reno prelude but made more readable + and friendly + + * Example: https://review.openstack.org/644697 + +Immediately after RC +-------------------- + +* Look for bot proposed changes to reno and stable/ + +* Create the launchpad series for the next cycle + +* Set the development focus of the project to the new cycle series + +* Set the status of the new series to “active development” + +* Set the last series status to “current stable branch release” + +* Set the previous to last series status to “supported” + +* Repeat launchpad steps ^ for python-novaclient + +* Register milestones in launchpad for the new cycle based on the new cycle + release schedule + +* Make sure the specs directory for the next cycle gets created so people can + start proposing new specs + +* Make sure to move implemented specs from the previous release + + * Use ``tox -e move-implemented-specs `` + + * Also remove template from ``doc/source/specs//index.rst`` + + * Also delete template file ``doc/source/specs//template.rst`` + +* Create new release wiki: + + * Example: https://wiki.openstack.org/wiki/Nova/Train_Release_Schedule + +Miscellaneous Notes +------------------- + +How to approve a launchpad blueprint +************************************ + +* Set the approver as the person who +W the spec, or set to self if it’s + specless + +* Set the Direction => Approved and Definition => Approved and make sure the + Series goal is set to the current release. If code is already proposed, set + Implementation => Needs Code Review + +* Add a comment to the Whiteboard explaining the approval, with a date + (launchpad does not record approval dates). For example: “We discussed this + in the team meeting and agreed to approve this for . -- + ” + +How to complete a launchpad blueprint +************************************* + +* Set Implementation => Implemented. The completion date will be recorded by + launchpad diff --git a/doc/source/index.rst b/doc/source/index.rst index acd4ed9ed462..ecf3fe727407 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -218,6 +218,7 @@ looking parts of our architecture. These are collected below. contributor/how-to-get-involved contributor/process contributor/project-scope + contributor/ptl-guide reference/api-microversion-history.rst reference/gmr reference/i18n