Open Stack

Mike,

Inline comments.

Vladimir,
> I think this call is too late to change a structure for now. I suggest
> that we always respect the policy we've accepted, and follow it.
>
> If Component Leads role is under a question, then I'd continue the
> discussion, hear opinion of current component leads, and give this a time
> to be discussed. I'd have nothing against removing this role in a month
> from now if we reach a consensus on this topic - no need to wait for the
> cycle end.
>

​Sure, there is no need to rush. I'd also like to see current CL opinions.




> I originally proposed this role in [1], and I've seen this working better
> than without it: with code reviews; getting a final decision faster with
> very little involvement of PTL. I would say that we needed to do analysis
> similar to what I've done in [1], in order to get better understanding of
> what worked well and what didn't.
>

> From my high level take here: Fuel is large project, counts 21 repos with
> code, excluding plugins [2]. While some of subprojects would have a clear
> leadership, some may get a few people with contradicting opinions but
> similar weight in the community. In this case, decision on contradicting
> opinions will be on a shoulders of PTL, which doesn't seem to be very
> scalable. Volunteering doesn't help in this case, as even two volunteers
> with different opinions will have to ask PTL for judgement.
> I'd let Dmitry B. to comment, but I don't think that we had too many
> things which could not be resolved on Component Leads level in the past
> cycle.
>

​
My opinion here is that if a component is generic enough and could be
treated as independent project, then this project should be brought out of
Fuel and have its own PTL. If a component is a part of Fuel then final
decision should be up to a Fuel PTL. That is how OpenStack works.
​If a project is so huge that requires kind of hierarchy, then it is a good
reason to decouple this project into a set of independent projects. What I
don't like in our current approach is that we have 21 repos and only 3
components. Why shouldn't we treat fuel-astute or fuel-agent or
fuel-nailgun-agent, etc. as valid components with their own CLs?
​
  ​
​


>
> A few other things answered inline:
> > Our CL role is rather a mixture of a manager and an architect.
> Why manager? Do we have any other Fuel contributors reporting to Component
> Leads? Yes for an architect. Is it a problem in the community?
>

​OpenStack has a role 'Core Reviewer' and it is a matter of the whole core
team to review patches in a repository. I see no reasons to have yet
another community supervisor who will poke core team to review patches. If
Mirantis or any other third party contributor wants to have a dedicated
person who reminds other people about patches that need to be reviewed it
is a matter of a particular company not of Fuel community. Such enterprise
role should not be exposed to Fuel as a community.

Architect (who has expertise over the whole Fuel) is also a role that
should not be exposed to Fuel. In community we have core reviewers and all
decisions should be a matter of consensus. If a company forces people to
support one opinion or another, then again it should be a matter of the
internal company hierarchy. Being a core reviewer in the community does not
mean a particular person can not be an architect or a manager inside a
company.   ​



> > If a particular manager wants to have a person who is to be responsible
> for asking people to review patches, then it is a matter of this manager to
> motivate a particular person.
> If you mean contributors, then established workflow with
> maintainers  [3] should cover this.
> If you mean Component Leads here, then I'd say that CLs have to be
> self-motivated to ensure on-time review on patches. Otherwise, people will
> turn out from component(s), and prefer other solutions or a fork.
>

​​Yes, I like very much our MAINTAINERS approach. It works well, it is easy
to know who is SME in a particular repository. IMO people who are mentioned
in MAINTAINERS should​ be volunteers. E.g. if I feel I'm an expert in
fuel-web, I send a patch that adds my name to MAINTAINERS file. Fuel-web
team then decides whether my feeling has something common with reality. But
real motivation behind the voluntary should NOT be exposed to the
community. For the community it does not matter why a person wants to
review or write the code. It does not matter if it is self-motivation or an
order of a manager.

The same approach could be used for reviewing specs. I.e. if we want to
make sure that a spec does not contradicts to the whole Fuel architecture,
then we just need trusted people to be mandatory reviewers. This could be
done using "Avengers" approach described above.
​

> CL has to make a decision, how many blueprints can be taken into work, to
> ensure that enough time is dedicated to code review and other activities.
>

​Nope. A component team makes decisions (consensus). If a team wants to
delegate their voice to a particular person (a member of the team), it is
ok. Consensus is a sum of arguments, not a sum of opinions. Opinions could
depend on many things (including salary, career). What you are describing
is a manager role. And it is ok to have managers (fuel-web or fuel-ui
manager) who help to coordinate resources. I'm only against this practice
of exposing enterprise roles to the community.


>
> Thanks,
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> [2]
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L593
> [3]
> https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow
>
> Thanks,
>
> On Fri, Mar 25, 2016 at 9:10 AM Vladimir Kozhukalov <
> vkozhukalov at mirantis.com> wrote:
>
>> Dear all,
>>
>> Let me raise my hand here. We introduced this role CL a while ago for two
>> major reasons:
>>  1) improve review process (CL are responsible for review SLA)
>>  2) introduce review of overall architecture and avoid cross-feature,
>> cross-component conflicts.
>> These two points, in fact, mean the following:
>>  1) CL ask other developers (including cores) to help to review patches
>> if there any that did not get enough attention
>>  2) CL spend 50% of their time reviewing specs and we don't merge specs
>> w/o their +2
>>
>> I think that is not exactly what we meant. Our CL role is rather a
>> mixture of a manager and an architect. Both these roles are enterprise
>> roles. I think in community having Core Reviewers is more than enough.
>>
>> Real motivation (salary, career, etc.) of a particular contributor should
>> NOT be a matter of community. If a particular manager wants to have a
>> person who is to be responsible for asking people to review patches, then
>> it is a matter of this manager to motivate a particular person. In
>> community a team of core reviewers is responsible for review, not a person.
>>
>> To prevent cross-feature and cross-component conflicts we can use CI gate
>> that will put -1 to a spec that is merged without necessary +2 from trusted
>> people from various components. For example, we could create a yaml file
>>
>> avengers:
>>   fuel-web:
>>     Hawkeye
>>     Captain America
>>   fuel-ui:
>>     Black Widow
>>   fuel-library
>>     Hulk
>>     Ironman
>>
>> and CI gate will check if there is +2 from at least one superhero from
>> every project and fail if not. Superheros should be volunteers (no matter
>> what their real motivation is).
>>
>> I propose to get rid of official CL role in Fuel. Instead it should be
>> totally up to a particular component team to decide if they want CL or
>> other roles. What do you guys think?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <
>> dborodaenko at mirantis.com> wrote:
>>
>>> Serg,
>>>
>>> Thanks for agreeing to officiate this cycle's component lead elections
>>> for us!
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>>
>>> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:
>>> > Hi folks,
>>> >
>>> > I'd like to announce that we're running the Component Leads elections.
>>> > Detailed information is available on wiki [0].
>>> >
>>> > Component Lead: defines architecture of a particular module or
>>> > component in Fuel, resolves technical disputes in their area of
>>> > responsibility. All design specs that impact a component must be
>>> > approved by the corresponding component lead [1].
>>> >
>>> > Fuel has three large sub-teams, with roughly comparable codebases,
>>> > that need dedicated component leads:
>>> >
>>> > * fuel-library
>>> > * fuel-web
>>> > * fuel-ui
>>> >
>>> > Nominees propose their candidacy by sending an email to the
>>> > openstack-dev at lists.openstack.org mailing-list, with the subject:
>>> > "[fuel] <component> lead candidacy"
>>> > (for example, "[fuel] fuel-library lead candidacy").
>>> >
>>> > Timeline:
>>> > * March 25 - March 31: Open candidacy for Component leads positions
>>> > * April 1 - April 7: Component leads elections
>>> >
>>> > References
>>> > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016
>>> > [1]
>>> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
>>> >
>>> > --
>>> > Serg Melikyan, Development Manager at Mirantis, Inc.
>>> > http://mirantis.com | smelikyan at mirantis.com
>>> >
>>> >
>>> __________________________________________________________________________
>>> > 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
>>>
>>
>> __________________________________________________________________________
>> 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
>>
> --
> Mike Scherbakov
> #mihgen
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160329/3d44b59e/attachment.html>