[openstack-dev] The Evolution of core developer to maintainer?

Thierry Carrez thierry at openstack.org
Fri Apr 3 08:39:59 UTC 2015

Joe Gordon wrote:
> On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
>>     Joe Gordon wrote:
>>     > 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).   

OK, so I probably misread your proposal[1]. My understanding was you
wanted a single flat "maintainers" group that would purely replace "core
reviewers", keep the same rights and just add duties to the
already-existing reviewing duties.

[1] https://review.openstack.org/#/c/163660/

Since I thought project leadership needs to be expressed in a much more
diverse and inclusive way (and explicitly not tied to +2 rights), I
opposed such simple renaming.

>From what you're saying now your objective is the same as mine. I'm not
sure the maintainers group needs to be purely hierarchical (I think I'd
prefer it to be a set of duties with no hierarchy between them), but I
agree that:

- today core reviewers are the only visible project duty, and we need to
expose and reward all the others, as separate attributes

- we could use a blanket term ("maintainers" ?) to describe the people
holding one or more of those attributes.

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

PTLs have (and always had) ultimate say over their project matters. That
includes how to select core reviewers (or how reviews should be
performed). A lot of projects let their PTL directly determine who
should (and should no longer) be on the core list.

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

Now it's true that very early on, a lot of PTLs adopted a more "open"
process to help in that selection. That doesn't mean they can't bypass
the process.

Personally I think that the apparently "open" process for core selection
just resulted in reinforcing the aristocracy. This is why I encourage
PTLs to own the content of core reviewing teams more directly.

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

The Swift PTL always just announced additions. I seem to remember
TripleO under Robert Collins directly adding members. Also Nova under
Russell Bryant removed inactive members without asking for an existing
core members poll. (and that is all good). That said, I agree with you
that most projects copied the "existing cores must agree" rule.

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

Obviously the PTL would only overrule the majority of his core reviewers
in extreme cases. Imagine this extreme case: core reviewers in a project
have become a pure aristocracy, nobody can get in anymore, fresh ideas
and code are systematically rejected. There is a divide between
contributors to the project (doing the work) and core reviewers. Project
is completely blocked. At the next election, a PTL candidate campaigns
on fixing this by dramatically changing the core team. Contributors
rally to that candidacy, candidate is elected. Once elected, the PTL can
fix the core team without asking the existing aristocracy blessing.

Now I agree that it's a governance safety valve, designed to solve a
mostly theoretical case. But sometimes having a "bucket stops here" rule
is sufficient to prevent conflict. For example conflicts between two
projects can be escalated to the TC for final resolution. In effect,
that never happens: said projects usually solve the issue between
themselves rather than ask the TC to arbitrate. The same effect applies
here: saying "the PTL has ultimate say anyway" usually prevents a total
disconnect between the contributors and the core reviewers, because
everyone knows there is a safety valve.

> [...]
> 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?

Define roles (separate from "core reviewing") that are useful tasks, and
let people hold those roles. For example we introduced this cycle the
concept of liaisons -- this is incredibly important work, and I'd like
the people who hold those roles to be more widely recognized.

Now the problem is how we give more recognition to those people. I've
been trying to popularize the use of the "CPL" acronym (cross-project
liaisons) as a key part of the project leadership (just below the PTL).
Maybe we need a blanket term ("maintainers" ?) to regroup all those roles ?

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

So I think that's a separate issue. Lack of core reviewers in Nova is
because the domain you have to have expertise on is just too big. That
means it is very hard to maintain the expertise and activity level to
remain a core reviewer, and even harder to learn enough to become one. I
fear the only solution there is to have separate core review teams
responsible for smaller areas of code. But that is a separate thread imho.

Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list