We had a double session on extended maintenance at the Forum in Vancouver, here is a late summary of it. Feel free to add to it if you remember extra things.

The first part of the session was to present the Extended Maintenance process as implemented after the discussion at the PTG in Dublin, and answer questions around it.

The process was generally well received, with question on how to sign up (no real sign up required, just start helping and join #openstack-stable). There were also a number of questions around the need to maintain all releases up to an old maintained release, with explanation of the FFU process and the need to avoid regressions from release to release.

The second part of the session was taking a step back and discuss extended maintenance in the context of release cycles and upgrade pain. A summary of the Dublin discussion was given. Some questions were raised on the need for fast-forward upgrades (vs. skip-level upgrades), as well as a bit of a brainstorm around how to encourage people to gather around popular EM releases (a wiki page was considered a good trade-off).

The EM process mandates that no releases would be tagged after the end of the 18-month official "maintenance" period. There was a standing question on the need to still release libraries (since tests of HEAD changes are by default run against released versions of libraries). The consensus in the room was that when extended maintenance starts, we should switch to testing stable/$foo HEAD changes against stable/$foo HEAD of libraries. This should be first done when Ocata switches to extended maintenance in August.

The discussion then switched to how to further ease upgrade pain, with reports of progress on the Upgrades SIG on better documenting the Fast Forward Upgrade process. We discussed how minimal cold upgrades capabilities should be considered the minimum to be considered an official OpenStack component, and whether we could use the Goals mechanism to push it. We also discussed testing database migrations with real production data (what turbo-hipster did) and the challenges to share deidentified data to that purpose.


Thierry Carrez (ttx)

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to