Thierry, thanks for writing this up. I think this is a great idea, and something that will help focus the release stewards on a specific release while the PTL can coordinate activities for all aspects of the project. Where appropriate, and where a project decides to take this route, it allows PTL's to distribute some of the load amongst others in the project team.
One other important benefit of this approach is, I believe, that we can expand the leadership pool within OpenStack by distributing the leadership activities to the release stewards. One of the conversations at the OpenStack SWG [1] and [2] has been to expand this leadership pool and I believe that this proposal for release stewards is a good step in that direction. Thanks, -amrith [1] https://review.openstack.org/#/c/337895/ [2] https://wiki.openstack.org/wiki/Meetings/SWGMeeting > -----Original Message----- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: Wednesday, September 07, 2016 11:44 AM > To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [all] Timeframe for future elections & "Release > stewards" > > 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 > > -- > 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 __________________________________________________________________________ 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
