9.7 KiB
9.7 KiB
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
- Update the team wiki
- Get acquainted with the release schedule
Project Team Gathering
- Create PTG planning etherpad, retrospective etherpad and alert about it in nova meeting and dev mailing list
- Run sessions at the PTG
- Have a priorities discussion at the PTG
- Sign up for group photo at the PTG (if applicable)
- Open review runways for the cycle
After PTG
- Send PTG session summaries to the dev mailing list
- Make sure the cycle priorities spec gets reviewed and merged
- 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:
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 <stable branch>git log --no-merges <last tag>..- 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
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:
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:
- 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:
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
Mark the max microversion for the release in the
/reference/api-microversion-history:
A few weeks before RC
- Make a RC1 todos etherpad and tag bugs as
<release>-rc-potentialand keep track of them, example: - Go through the bug list and identify any rc-potential bugs and tag them
RC
- Do steps described on the release checklist wiki:
- 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:
- “Merge latest translations" means translation patches
- Check for translations with:
- 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.opendev.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.opendev.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.opendev.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.opendev.org/644697
Immediately after RC
- Look for bot proposed changes to reno and stable/<cycle>
- Follow the post-release checklist
- https://wiki.openstack.org/wiki/Nova/ReleaseChecklist
- Add database migration placeholders
- Example: https://review.opendev.org/650964
- Drop old RPC compat code (if there was a RPC major version bump)
- Example: https://review.opendev.org/543580
- Bump the oldest supported compute service version
- 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 <release> - Also remove template from
doc/source/specs/<release>/index.rst - Also delete template file
doc/source/specs/<release>/template.rst
- Use
- Create new release wiki:
- Update the contributor guide for the new cycle
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 <release>. -- <nick> <YYYYMMDD>”
How to complete a launchpad blueprint
- Set Implementation => Implemented. The completion date will be recorded by launchpad