Open Stack

On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez <thierry at openstack.org>
wrote:

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


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

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
> 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/20150403/3dd2a7e2/attachment.html>