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. -- Thierry Carrez (ttx) __________________________________________________________________________ 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
