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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
