Open Stack

On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> Joe Gordon wrote:
> >>     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.
>
> And would you describe that as a good thing ? If John Garbutt is so deep
> into release liaison work that he can't sustain a review rate suitable
> to remain a core reviewer, would you have him removed from the
> "maintainers" group ? If someone steps up and works full-time on
> triaging bugs in Nova (and can't commit to do enough reviews as a
> result), would you exclude that person from your "maintainers" group ?
>

I want to empower that person and recognize them in some semi formal
capacity and make sure they have all the correct permissions.

I do not want a single flat 'maintainers' group, I think we need a
hierarchical notion of maintainers, where different people can end up with
very different responsibilities (and ACLs -- but that is a implementation
detail).


>
> >>     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.
>
> I think we are talking past each other. I'm not saying bug triagers have
>

It appears that we are talking past each other, at least we agree on
something.


> to be drivers. I'm saying bug triagers should be *allowed* to
> potentially become drivers, even if they aren't core reviewers. That is
> including of all forms of project leadership.
>
> You are the one suggesting that maintainers and core reviewers are the
> same thing, and therefore asking that all maintainers/drivers have to be
> core reviewers, actively excluding non-reviewers from that project
> leadership class.
>
> >>     Saying core reviewers and maintainers are the same thing, you
> basically
> >>     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.
>
> You've been proposing to rename "core reviewers" to "maintainers". I'm
> not sure how that can be more tightly coupled...
>

All core reviewers in our current model should be responsible for
maintenance of the project, but not all maintainers need to be responsible
for reviewing code anywhere in the project.


>
> > [...]
> > I really want to know what you meant be 'no aristocracy' and the why
> > behind that.
>
> Aristocracies are self-selecting, privileged groups. Aristocracies
> require that current group members agree on any new member addition,
> basically limiting the associated privilege to a caste. Aristocracies
> result in limited gene pool, tunnel vision and echo chamber effects.
>
> OpenStack governance mandates that core developers are ultimately the
> PTL's choice. Since the PTL is regularly elected by all contributors,
> that prevents aristocracy.


Can you site your source for this? Because the earliest reference to 'Core
Developer' (what you are calling core reviewer -- even though that is not
the original name) that I could find says nothing about it ultimately being
the PTLs choice.

https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Where is the current documentation on this?


>
> However in some projects, core reviewers have to be approved by existing
> core reviewers. That is an aristocracy. In those projects, if you
>

Which projects do it differently?

So this is where you loose me. Has there ever been a case of a project's
PTL adding/removing people from the core team where the PTL goes against
the majority of the core developers?  You say that an early (unwritten?)
goal of the system we have is to prevent 'aristocracy,' but all I see is
'aristocracy'.

It sounds like if a goal was no aristocracy then we have miserably failed
at that. But frankly I don't know to prevent what you call aristocracy.



> associate more rights and badges to core reviewing (like by renaming it
> "maintainer" and bundle "driver" responsibilities with it), I think you
> actually extend the aristocracy problem rather than reduce it.
>

So, let me take a step back here. I would like to see at least 2 to 3x more
people in a given project to feel empowered and have badges, and make it
possible for part time upstream developers to hold some of said badges.  It
sounds like you more or less agree with that goal. So how do you propose we
get there?

Because having 15 core reviewers for all of nova is just not cutting it.


>
> --
> 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/20150402/0a26b95c/attachment.html>