Open Stack

Hi everyone,

TL;DR:

- In an effort to reduce useless work, in Liberty we'll switch from
trying to accurately predict what will end up in milestones to reporting
what actually landed.

- We'll also replace weekly release management 1:1 sync points with
office hours.

- For Liberty we'll have two release managers: Doug Hellmann agreed to
serve as release manager for this cycle.

Long version:

During the Kilo cycle I reviewed the release management processes, with
an eye to scaling to support more projects needs. In Kilo and previous
releases, one of the goals of release tracking was to try to communicate
what is likely going to land in the cycle, by maintaining our collective
best attempt at a prediction. This was done by constantly refining the
list of blueprints that are likely to land for each milestone during
weekly 1:1 syncs. One of the things we quickly agreed on with PTLs was
that this part of the release tracking, as performed, was not very
useful and took way too much time. It became so unreliable recently that
nobody was actually using that prediction anymore, and it took way too
much time for PTLs and release managers to try to maintain it.

So we decided to switch from prediction to reporting. The proposed
change in Liberty is to stop using Launchpad milestone pages before a
milestone is actually completed (i.e. stop trying to predict). We'd just
use milestones /after/ a blueprint is completed, the same way we add the
milestone target to fixed bugs, in order to track what features and
bugfixes a milestone actually ends up containing.

Now, if they really want to, teams may still opt to use Launchpad to
track release cycle main goals. This can be achieved by setting the
"series goal" on a blueprint to build a series-specific blueprint list.
The release status page will be reworked to primarily communicate the
completed work, and secondarily show the status of the in-progress work
on the series (without necessarily promising when it shall land).

In the new world order:

- Assignees should still file and maintain the status of their blueprint
(in particular, set it to "Started" when started and to "Implemented"
when completed)

- Release liaisons may opt to track their specific cycle goals by
setting the series goal (not mandatory)

- Assignees may target their blueprint to a future milestone, as a
non-binding indication of when they intend to land it (not mandatory)

- When we reach a milestone, release management will add any blueprint
"implemented" during the milestone timeframe to the milestone release page

- When we reach a milestone, release liaisons should make sure we don't
miss a key feature (and retroactively file an implemented blueprint if
that's the case)

This should all result in a lot less friction and coordination needs, to
the point where we don't need weekly 1:1 syncs between release liaisons
and release manager anymore. We propose to replace them by:

- communications of general information during the cross-project meeting

- release management office hours, during which release liaisons can
come with their questions

Those would happen on Tuesdays in #openstack-relmgr-office, from
0800-1000 UTC and 1800-2000 UTC for complete timezone coverage. The only
obligation for release liaisons would be to come sync during release
management office hours on milestone/release weeks.

Additionally, it is my pleasure to announce that Doug Hellmann will
serve as an additional release manager for the Liberty cycle. There is
no longer an "OpenStack release manager", but a real "Release management
team" !

Let me know if you see any issue with the proposal. It was exposed to
(and approved by) PTLs during the Kilo cycle and the plans were
confirmed during a cross-project session at the Vancouver Design Summit,
but we can still consider adjustments.

Thanks for reading until the end!

-- 
Thierry Carrez (ttx)