[openstack-dev] The Evolution of core developer to maintainer?
joe.gordon0 at gmail.com
Fri Apr 3 17:35:33 UTC 2015
On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez <thierry at openstack.org>
> 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
> >> into release liaison work that he can't sustain a review rate
> >> 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. 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.
>  https://review.openstack.org/#/c/163660/
So that proposal was not the end goal it was supposed to be a very tiny
first step down this path. I see how that was misleading.
> 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
Hierarchical, in the sense of subsystem maintainers. Not all duties would
have to be that way though.
> 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
> >> PTL's choice. Since the PTL is regularly elected by all
> >> 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
> >> 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.
It sounds like writing down this aspect of the PTL powers may be something
worth writing down in the governance repo somewhere?
> > 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
While a safety valve like this is fine, I am not sure if its existence is
why these issues have never arose, and have a hard time imagining this
safety valve actually being used.
If this did happen there is a better safety valve IMHO, the fork.
> 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.
Makes sense, but I still think the current role of 'core reviewer' it self
needs to be decomposed further (see below for more on this).
> 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.
Yes the crux of the core reviewer issue in nova and other projects is
directly related to the size/activity of the repo in question. One of the
main goals in my head of starting this thread was to better address this
specific question. I have a few possible ideas on how we can address this,
but right now I am trying to at least get agreement that the current 'core
reviewer' model for large repositories is not working.
> Thierry Carrez (ttx)
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev