Open Stack

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: September-09-16 8:19 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> On 08/09/16 18:41 +0000, Hongbin Lu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Thierry Carrez [mailto:thierry at openstack.org]
> >> Sent: September-08-16 5:00 AM
> >> To: openstack-dev at lists.openstack.org
> >> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> >> "Release stewards"
> >>
> >> 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.
> >>
> >> So... the difference between your proposal and mine is: you force
> the
> >> PTL to be the release steward (rather than having a choice there),
> >> and introduce a delay between election and start of authority for
> the PTL.
> >>
> >> I don't see that delay as a good thing. You would elect in April a
> >> PTL whose authority over the project would start in August. That
> >> sounds a bit weird to me. I'd rather say that the authority of the
> >> PTL starts when he is elected, and not introduce a delay.
> >
> >If the authority of the PTL starts in the middle of a cycle, what
> happen if the just-elected PTL disagree with what were planned by the
> previous PTL? Does the just-elected PTL have authority to override what
> were planned? For contributors, it is confusing to have two PTLs in one
> cycle. They might follow the instruction from one PTL to setup the plan
> for the whole cycle. Then, in the second half of the cycle, the new PTL
> give a totally different instruction for the same item. As a result,
> the plan needs to be changed or extra efforts are needed to ensure the
> new PTL agrees with the original plan. In this case, introducing
> "release stewards" doesn't solve the problem because this new role
> doesn't have final says.
> 
> I think you're pushing the role of the PTL a bit too far, or at least
> how PTLs should interact with the community. I've written about this in
> the past:

Maybe, but I was not arguing the role of the PTL. I was arguing it is confusing to have two PTLs in one cycle.

> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-
> September/073986.html
> 
> Flavio
> 
> >>
> >> I don't see *forcing* the PTL to be the release steward to be a good
> >> thing either. The just-elected PTL can totally be the release
> steward
> >> for the upcoming cycle -- actually, that is how my proposal would
> >> work by default: the PTL elected around Boston would be the default
> >> release steward for Q, and the PTL elected around Sydney would be
> the
> >> default release steward for R. But I'd rather allow for some
> >> flexibility here, in case the PTL prefers to delegate more of his
> >> work. I also think allowing for more leadership roles (rather than
> >> piling it all on the
> >> PTL) helps growing a stronger leadership pipeline.
> >>
> >> In summary, I see drawbacks to your variant, and I fail to see any
> >> benefits... Am I missing something ?
> >>
> >> --
> >> Thierry Carrez (ttx)
> >>
> >>
> _____________________________________________________________________
> >> __
> >> ___
> >> 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
> 
> --
> @flaper87
> Flavio Percoco