Open Stack

Comments/praise in-line.

On 5/28/15 11:54 AM, Thierry Carrez wrote:
> 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.
Glad to hear.
> - We'll also replace weekly release management 1:1 sync points with
> office hours.
Works for me.
> - For Liberty we'll have two release managers: Doug Hellmann agreed to
> serve as release manager for this cycle.
Nice!
>
> 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.
This works for me.
> 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" !
Kudos
> 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!
>

Thanks Thierry and Doug, this is really nice plan.

-- 

Cheers,
Nikhil