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) __________________________________________________________________________ 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
