On 9/7/2016 11:35 AM, Ian Cordasco 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.
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
Membership in the stable team doesn't really have anything to do with
whether or not you're a PTL or release liaison, it has everyone to do
with your ability to review patches and follow the stable backport
policy. Not all cores on master are on the stable team for a project,
and vice-versa, including the PTL.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
