Open Stack

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

-- 
Sean Dague
http://dague.net