On 09/07/2016 11:43 AM, Davanum Srinivas wrote: > On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: >> >> >> -----Original Message----- >> From: Monty Taylor <mord...@inaugust.com> >> Reply: OpenStack Development Mailing List (not for usage questions) >> <openstack-dev@lists.openstack.org> >> Date: September 7, 2016 at 10:58:52 >> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org> >> 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).
I think they should be. If they are the Steward of the Pike release, then I personally think that's a position that's attached to the lifecycle of the release, not a fixed period of time - even though over time it's likely more the stable team driving things and less the Release Steward. But, as usual, that may just be me. __________________________________________________________________________ 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
