On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> Barrett, Carol L wrote:
>> From: Sean Dague [mailto:s...@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
__________________________________________________________________________
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
