Open Stack

Good comment and I have an answer inline.



On 9/8/16 2:41 PM, 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.

Firstly, I'd like to say that the wording is bit strong here but I can
see where it may be coming from.

To be fair to all (i.e. generalizing this a bit), I think the PTL is
more of a guide than authority. Nevertheless, veto "does" belong to the
PTL but too many veto-s means misuse of authority and the veto loses its
value. So, a PTL, in most cases, doesn't give 'instructions' (well
unless you are doing fixed-timeline work like releases), PTL is supposed
to facilitate with planning, co-coordinating different interest parties,
determining the priorities/preferences, make educated guesses for the
feature and core bandwidth, etc.

So.. in a good coherent community (which is what each project should aim
for) we won't have drastically varying decisions during the transition
phase (PTL elections). Also, the elections should indicate that the new
PTL should respect the decisions that were taken by the former one.
Dissolving the power (or rights) from the PTL to more people in the team
(like in this case the release stewards) will ensure a check on anyone
having radical (very different) ideas in the middle of a running cycle.

To be even more specific, with this new approach, the new PTL gets
enough time to focus on new specs, proposals in backlog, bugs that will
increase there relevance in the upcoming months etc. and put up a strong
agenda or timeline for the next release. This works great for
particularly mature projects but I'm sure newer projects don't have much
to lose either. Newer projects will usually have smaller teams, may even
have the same set of people/stewards/PTL for a few cycles and when these
projects mature they benefit from this election process.

About the final say, I agree that we've traditionally said that PTL has
final say on the release work. But if you look closer, now the PTL is
assigned early on for the next cycle and doesn't have the final say on
the release for this cycle. So, after the elections release steward
takes on or should take on the responsibility to see this release
through. (Of course, as this question will arise in other minds, we need
more semi-permanent documentation for this).

This plan does result into a bad experience in cases of smaller teams
with more churn rate of developers. The planning and preferences of the
project could change dynamically and having to plan a few months before
the start of a release will result into a non-deterministic challenging
experience for the PTL. Some projects won't have the option to choose
intermediary release due to maturity level so, that's not a solution. If
we adopt the new approach, this problem needs to be solved (but in
practice and not using process).

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


-- 

Thanks,
Nikhil