Open Stack

On Wed, Apr 1, 2015 at 2:41 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> Joe Gordon wrote:
> > I am starting this thread based on Thierry's feedback on [0].  Instead
> > of writing the same thing twice, you can look at the rendered html from
> > that patch [1]. Neutron tried to go from core to maintainer but after
> > input from the TC and others, they are keeping the term 'core' but are
> > clarifying what it means to be a neutron core [2]. [2] does a very good
> > job of showing how what it means to be core is evolving.  From
> >
> >     "everyone is a dev and everyone is a reviewer. No committers or repo
> >     owners, no aristocracy. Some people just commit to do a lot of
> >     reviewing and keep current with the code, and have votes that matter
> >     more (+2)." (Theirry)
> >
> > To a system where cores are more then people who have votes that matter
> > more. Neutron's proposal tries to align that document with what is
> > already happening.
> >
> >     1. They share responsibility in the project's success.
> >     2. They have made a long-term, recurring time investment to improve
> >     the project.
> >     3. They spend their time doing what needs to be done to ensure the
> >     projects success, not necessarily what is the most interesting or
> fun.
>
> A bit of history is useful here.
>
> We used[1] to have 4 groups for each project, mostly driven by the need
> to put people in ACL groups. The PTL (which has ultimate control), the
> Drivers (the trusted group around the PTL which had control over
> blueprint targeting in Launchpad), the Core reviewers (which have +2 on
> the repos in Gerrit), and the bug team (which had special Launchpad bugs
> rights like the ability to confirm stuff).
>
> [1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups
>
> In that model, "drivers" is closer to what you describe for
> "maintainers" -- people invested 100% in the project success, and able
> to spend 95% of the work time to ensure it.
>
>
I am having a hard time aligning your description to what we have today.

This comparison misses what IMHO is the most important parts of the
maintainers model, subsystem maintainers.  Maintaining a subsystem doesn't
need to be a full time job.


> My main objection to the model you propose is its binary nature. You
> bundle "core reviewing" duties with "drivers" duties into a single
> group. That simplification means that drivers have to be core reviewers,
> and that core reviewers have to be drivers. Sure, a lot of core
> reviewers are good candidates to become drivers. But I think bundling
> the two concepts excludes a lot of interesting people from being a
> "driver".
>

I cannot speak for all projects, but at least in Nova you have to be a
nova-core to be part of nova-drivers.


>
> If someone steps up and owns bug triaging in a project, that is very
> interesting and I'd like that person to be part of the "drivers" group.
>

In our current model, not sure why they would need to be part of drivers.
the bug triage group is open to anyone.


> That said, bug triaging (like core reviewing) is a full time job. You
> can't expect the person who owns bug triaging to commit to the level of
> reviewing that core reviewers commit to. It's also a different skillset.
>
> Saying core reviewers and maintainers are the same thing, you basically


I don't want to make it harder for people to feel empowered to help, I want
to make it easier.


> exclude people from stepping up to the project leadership unless they
> are code reviewers. I think that's a bad thing. We need more people
> volunteering to own bug triaging and liaison work, not less.
>

I don't agree with this statement, I am not saying reviewing and
maintenance need to be tightly coupled. Why do we review code?
http://docs.openstack.org/infra/manual/developers.html#code-review gives a
incomplete list of what we are looking for. But I think it boils down two
two general components:

* Does the change make sense in the context of the project?
* Does the patch pass our code quality requirements (testing, pythonic,
formatting, commit message, logging etc.)?

If someone doesn't have a good grasp of the code they are trying to
maintain they won't be able to review if the patch makes sense or not. In
this case, yes you really cannot be responsible for a piece of code if you
don't understand it -- but we have this constraint today. As for the second
aspect of reviewing, this has a lot less to do with what the patch is doing
and instead how it is doing it. There is no reason reviews for code quality
need to be coupled with anything else.


I think our idea of combining two separate review criteria into a single
review (and ACL) is making things more confusing.


> So, in summary:
>
> * I'm not against reviving the concept of drivers
> * I'm against making core reviewing a requirement for drivers

* I'm for recognizing other duties (like bug triaging or liaison work)
> as being key project leadership positions
>
> Hope this clarifies,
>

I really want to know what you meant be 'no aristocracy' and the why behind
that.


>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150401/b8e050bd/attachment.html>