> -----Original Message----- > From: Sean McGinnis [mailto:sean.mcgin...@gmx.com] > Sent: September-07-16 3:17 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [all] Timeframe for future elections & > "Release stewards" > > 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: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 > > 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.
+1 > > > > > -- > > 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 > > _______________________________________________________________________ > ___ > 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 __________________________________________________________________________ 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