> -----Original Message----- > From: Flavio Percoco [mailto:fla...@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:thie...@openstack.org] > >> Sent: September-08-16 5:00 AM > >> To: openstack-dev@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: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. > >> > >> 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- > >> 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 > > -- > @flaper87 > Flavio Percoco __________________________________________________________________________ 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
