The release management team gathered at the PTG on Monday afternoon,
then together with the stable and requirements teams on Tuesday
afternoon. Most of the time was spent reviewing the Pike plan and
priorities. In case you missed it, the Pike schedule was made official
and published at:
Release process changes
The high priority for Pike is to fix the aclmanager tool (which we use
to set pre-release ACLs on stable/$series branches) so that it supports
editing the existing ACL in place rather than just adding a new one.
Another Pike priority is to adjust deadlines for cycle-trailing
deliverables, so that their Feature Freeze is around RC1 time, and their
RC1 around release. The current setup (where only the final release is
moved two weeks after) prevents them from integrating late changes.
We plan to create a "new project checklist" for things projects need
to do to align with release management when they join the big tent.
In terms of release tracking, we decided we want the releases.o.o
website to cover all cycle-based deliverables, which means that they
should all go through the releases repository (that should already be
the case). For "independent" projects, we'd like the site to contain
accurate information about a deliverable, or no information at all.
Therefore projects that don't keep that information up to date will be
removed in order to avoid publishing wrong data.
Minor changes in the process will be introduced to reduce the risk of
projects and libraries having no release come milestone-3, to encourage
libraries with versions < 1.0 to move to 1.0+, and better document which
changes are acceptable in pre-release branches.
Release automation is now mostly in place. The priority here is to
port all release tools and automation to work under Python 3.
Other changes include fixing the step in the branch script that tries
to fix the upper constraints url (and does not work on every repo), do
not propose contraint updates for pre-release versions, improve
validation for NPM projects, and allow stable branches for tagless
projects like devstack or grenade.
Priority is to consolidate release tools that use the releases
repository data in the releases repository (rather than spread them over
Beyond the upcoming 2.1 release, Reno will be mostly in maintenance
mode. The main missing feature would be to find a way to include release
notes in tarballs, but the exact approach is still being defined (and
may be solved at CI level rather than in-reno).
We'll also investigate more deeply what "releasing" would look like
for Go artifacts (beyond distributing signed source code tarballs).
That is all I remember and could extract from the notes. Other items
looked like they belonged to the stable and requirements teams. If I
missed anything significant let me know :)
Thierry Carrez (ttx)
OpenStack Development Mailing List (not for usage questions)