Hi everyone, 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:
https://releases.openstack.org/pike/schedule.html 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. Automation changes ------------------ * 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. Other ----- * Priority is to consolidate release tools that use the releases repository data in the releases repository (rather than spread them over two repos) * 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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
