On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Joe Gordon wrote: > > On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <thie...@openstack.org > > <mailto:thie...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
