Open Stack

On 07/09/16 12:02 -0500, Monty Taylor wrote:
>On 09/07/2016 11:43 AM, Davanum Srinivas wrote:
>> On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: Monty Taylor <mordred at inaugust.com>
>>> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
>>> Date: September 7, 2016 at 10:58:52
>>> To: openstack-dev at lists.openstack.org <openstack-dev at 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.

Not just you! I agree with this, it sounds like a good fit and match of
responsibilities. As you pointed out, Monty, most of the time the stable team
will drive things.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/8da0ed4c/attachment.pgp>