Open Stack

> -----Original Message-----
> From: Sean McGinnis [mailto:sean.mcginnis at 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: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.

+1

> 
> >
> > --
> > 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
> 
> _______________________________________________________________________
> ___
> 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