Open Stack

On Wed, Sep 07, 2016 at 01:07:22PM -0400, Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> > Barrett, Carol L wrote:
> >> From: Sean Dague [mailto:sean at dague.net] 
> >>> I think another option would be to run the PTL election early, but just don't have the turn over happen until the master release opens up. The current transition period is > > > 
> >>> actually quite short as noted by the comments around how design summit planning happens. Having the PTL-next elected half way through the cycle, but having PTL current > 
> >>> still > own landing the current release actually provides a lot more transition time.
> >>>
> >>> 	-Sean
> >>
> >> I had a similar thought to Sean's, with a few changes. Why not have a PTL own the release from start to finish, with the PTL for the next release getting elected as above. In this model, it would probably be advisable (or a guideline) that a PTL not run for 2 cycles in a row, because the work load would be unmanageable. This approach could help to grow a stronger leadership pipeline for each project and provide more opportunities for people in the team to grow their skills and take on leadership.
> > 
> > The drawback of this approach is that it breaks the governance model
> > around project teams. You need a "the buck stops here" person (even if
> > that power is seldom used). But you can't have two -- what happens if
> > they disagree ?
> > 
> > So it's simpler to have a single PTL at all times and one or two release
> > liaisons at all times. Could be the same person though.
> 
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a stable
> branch. It doesn't seem like it breaks anything to me.
> 
> 	-Sean

In the <5 minutes I've taken so far to digest this thread, this is my
preference. It gives the incoming PTL extra run time to start planning
and thinking about their cycle. There would be less transition time
between PTLs and the incoming PTL can start making the decisions like
Summit planning that will impact them.

It's at least a simpler transition from where we are to where we want to
be.

> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev