[openstack-dev] [all] Timeframe for future elections & "Release stewards"

Doug Hellmann doug at doughellmann.com
Wed Sep 7 15:57:37 UTC 2016


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



More information about the OpenStack-dev mailing list