On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <[email protected]> wrote: > > > -----Original Message----- > From: Monty Taylor <[email protected]> > Reply: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Date: September 7, 2016 at 10:58:52 > To: [email protected] <[email protected]> > Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release > stewards" > >> On 09/07/2016 10:43 AM, Thierry Carrez wrote: >> > 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. >> >> I think this is a great idea. Having a person be on point for a >> particular release from inception to whenever we stop caring about it >> makes a lot of sense. > > I agree. Regardless of how PTL elections end up working, I think we should > definitely move forward with this "Release Stewards" concept. It sounds like > an excellent idea.
Also since "Release Stewards" are nominated by PTL, projects can just start using this concept right away (as it's not an elected position). +1 from me. > One question, should "Release Stewards" also be members of the Stable Team > for that project or will they become members of the Stable Team? It seems > like there should be a relationship there to me (although maybe not a > strictly enforced one). > > -- > Ian Cordasco > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
