Open Stack

Thierry Carrez <thierry at openstack.org> wrote:

> Ihar Hrachyshka wrote:
>> [...]
>> I slightly disagree with enforcing another formal role to all teams. I
>> feel that we have enough of them (release liaison for one) to cover for
>> release cross-project work, and projects are free to set their teams
>> with more roles if needed.
>
> You should probably re-read what I wrote, because there is no
> "enforcement" at all. There is merely the added possibility for teams to
> pick someone different for release liaison work per-cycle, so that the
> person preparing the next cycle is not necessarily the same person who
> works on completing the release. Quoting my original email: "some teams
> [...] may want to use the same super-human to handle everything [...],
> and some others might use two or three humans to spread the load”.

Well, unless you won’t request projects to designate someone specific for  
the role, you enforce it. But that’s not my main problem with the proposal,  
and I can live with another name assigned to release liaison, I am more  
concerned about switching the PTL that oversights the team in the middle of  
release cycle.

>
>> I somewhat disagree with attempt to document a single project team
>> hierarchy and impose, top to bottom, same roles on everyone irrespective
>> to project needs. I understand the need of some ‘liaison’ roles where
>> project decisions influence other projects, but I feel that now we get
>> into over-formalizing internal project structure. New roles in a team
>> should be generally driven by actual needs, from the bottom.
>
> Define "bottom". The need for a release liaison comes from the Release
> Management Team, just as the need for an Oslo liaison comes from the
> Oslo team. In case this is not clear, the idea of having "release
> stewards" comes from the Release Management Team. Quoting my original
> email: "a sort of per-cycle release liaison on steroids”.

There is a significant difference between release liaison role defined to  
handle cross project work, and release steward defined for what seems to be  
purely internal project matters.

>
>> I very much disagree with the idea of switching PTL in midterm. I
>> believe in some cases this proposal will add unnecessary rivalry in
>> lives of projects.
>
> Define "midterm". If you take into account that the work on a release
> cycle starts well before the development branches are open, then it's
> the current elections that happen "midterm". Whenever you choose, it's
> always at the start of something and the middle of something else.

 From where I came (neutron), it does not happen that way, but maybe we are  
just bad at handling release cycles? We have release cut-off as an  
opportunity to clean the slate and reconsider our direction for the next  
release. I don’t think introducing a structure that will allow for  
significant direction changes in the middle of the release cycle will be to  
the benefit of the project.

But having earlier elections for more smooth power transition would.

Ihar