[openstack-dev] [release] summit fishbowl summary

Doug Hellmann doug at doughellmann.com
Wed May 4 15:29:51 UTC 2016

Last week we had a retrospective for the Mitaka release and a planning
session for the Newton release. The notes are in the etherpad [1],
and this email is a summary based on those notes. As usual, if I've left
out something important or mis-remembered something, please post a



The overall sentiment expressed by distro folks in the room was that the
Mitaka release went well and was somewhat less stressful than the Liberty
release. In particular with the shorter release candidate period we had
fewer feature freeze exceptions requested and granted, which in turn
resulted in fewer release candidates. It's great to hear the positive
outcome, and we hope to eliminate some of the remaining friction this
cycle through more automation and education of project teams.

Regarding that education, one of the main sources of issues is PTLs and
liaisons not seeing or reading emails from the release team. There's a
lot of volume on this mailing list, so we're going to make a few changes
to make it easier to see the important notices. For instance, we agreed
that mixing release announcement emails and release team notices by using
the same [release] tag wasn't optimal. We'll be changing the tag used for
release announcements, since that should ultimately introduce the least
amount of confusion for PTLs and liaisons who are already subscribed to
the [release] topic (you *are* already subscribed, right?). More details
on that will come soon when we make the change.

Another issue we ran into late in the cycle was teams not understanding
the ramifications of the independent release model. We have added the
cycle-trailing model and are encouraging some other teams to use the
cycle-with-intermediary model to address those concerns.

Final Release Process Changes

>From a process perspective, one of the most manually intensive tasks we
have left is tracking release candidates from project teams. We discussed
various options for building a dashboard to track that information, but
pulling the information together automatically can be difficult because
sometimes the artifact we would use for tracking doesn't exist (there's
not a bug yet, etc.). We're going to be experimenting with having the
project teams manage their status directly this cycle, with the release
team facilitating but not trying to track each project ourselves. We need
to document the process for this, so we'll have more details closer to
the end of the cycle when the changes come into play. In the mean time,
we will continue to follow date-based deadlines for the major milestones
on the schedule [2], and expect PTLs/liaisons to submit tag requests on
their own as they did for Mitaka.


A few folks brought up the issue of communication about release freeze
periods, and in fact enforcing those periods at appropriate times such
as before major holidays. We will be adding details about freeze dates
to the schedule for dates we know in advance, and doing a better job of
communicating freezes (scheduled or otherwise, such as this week). Aside
from full freezes, keep in mind that we tend not to perform releases on
Thursday or Friday (as defined in the western hemisphere).

Expanding Automation

During the Mitaka cycle we took major steps in automating the release
review process, giving us the ability to manage releases the way we do
most everything else in the community, with someone to double-check
our work. We plan to further automate the process during Newton,
and as a result the release team is comfortable expanding beyond the
release:managed projects to any project using a cycle-based release
model. The changes needed for that expansion have already been made in
the project-config repository. If you used to have the ability to tag
releases directly, but cannot now, that's why. Drop by #openstack-release
if you need help getting set up with the openstack/releases repository.

Requirements Team

We had several discussions throughout the week about spinning out a
separate team to manage the openstack/requirements repository. Without
a volunteer to lead the team, we agreed to spend the first few months
mentoring some new reviewers and to have another discussion about a new
team somewhere mid-cycle. If you are interested in getting involved in
that work, please add your name to the list on [3] and start participating
in reviews.

[1] https://etherpad.openstack.org/p/newton-release-fishbowl
[2] http://releases.openstack.org/newton/schedule.html
[3] https://etherpad.openstack.org/p/newton-relmgt-plan

More information about the OpenStack-dev mailing list