Doug, Thierry, Do we want the stewards to serve as the CPL for Release team as well?
-- Dims [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management On Wed, Sep 7, 2016 at 11:57 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Thierry Carrez's message of 2016-09-07 17:43:59 +0200: >> Hi everyone, >> >> As you probably know by now, starting with the Boston event in 2017, the >> Summit will happen further away from the release day and more around the >> middle of the next development cycle. You can find more info on the >> rationale for that at [1] and [2] if interested, this is not the topic >> of this email. >> >> One interesting side-effect is that since the timing of the election >> period (for PTL and TC positions) is defined in the TC charter[3] >> relative to the *Summit*, it means that (unless we change this) we'll >> now run elections to renew PTL and TC positions in the middle of the >> cycle. Crazy, right ? That's what I first thought. But after discussing >> it with various people, this is not as crazy as it sounds. >> >> First, the current election timing is not perfect -- we change PTLs in >> the middle of the design summit prep, with old PTLs making Design Summit >> space requests that will affect their successor. It's not as if there >> was a perfect timing for doing elections. >> >> Second, release cycles are longer than 6 months. They actually start a >> few months before actual development starts, with discussions on next >> cycle priorities and Design Summit prep. They continue a few months >> after release, with critical stable branch backports and communication >> about landed features. So they are one year-long, overlapping cycles >> (like explained on the diagram at [4]). With that in mind, the PTL/TC >> election actually would happen just before the start of the start of the >> requirements-gathering pre-development phase of the next development >> cycle, which makes a lot of sense. >> >> Now, the main drawback of holding elections in the middle of a >> development cycle is that you don't want to introduce a discontinuity in >> leadership in that development cycle. To mitigate that, we propose the >> introduction of a new role, the "release steward", which would be >> attached to the release cycle. That person (who may or may not double as >> PTL) would be responsible for a complete release cycle on a given >> project team, from requirements gathering phase to post-release >> bugfix-backport phase. A sort of per-cycle release liaison on steroids. >> >> Since development cycles overlap, there would be two active release >> stewards at all times. This would help with the awkward situation where >> the PTL ends up having to think about the next cycle and prepare the >> Design Summit (or PTG) while still being knee-deep juggling with feature >> freeze exceptions, getting the current release out of the door, and >> coordinating early critical fixes stable backports. Those two jobs could >> be held by two different people. >> >> Now, some teams (especially those doing intermediary releases) may want >> to use the same super-human to handle everything (PTL, release steward, >> release+1 steward), and some others might use two or three humans to >> spread the load. That's up to them. But once designated by the >> newly-elected PTL, the release steward would be responsible for the full >> release cycle and would not be displaced by the next PTL 6 months later. >> One year being a long time, if a steward needs to step down, the >> currently-active PTL would appoint someone else to finish the job. >> >> With this new concept I think we can get the best of both worlds, and >> keep the election period as currently defined in the charter (rather >> than having to change it). The PTLs we will elect in the coming weeks >> won't be renewed before April, 2017 -- while Pike development will start >> in February. >> >> I know this can all be a bit confusing, so feel free to reach out to me >> with questions on this. >> >> [1] http://www.openstack.org/ptg >> [2] http://www.openstack.org/ptg/ptgfaq/ >> [3] >> http://governance.openstack.org/reference/charter.html#election-for-ptl-seats >> [4] >> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png >> > > Thanks for writing this up, Thierry. It sounds similar to what I > know a few companies are already doing internally. It should help > with continuity upstream, too, since the steward will work on a > given release through its whole life-cycle, rather than handing off > each time a new release cycle starts. > > Doug > > __________________________________________________________________________ > 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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