<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Joe Gordon wrote:<br>
> On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a><br>
</span><span class="">> <mailto:<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>> wrote:<br>
><br>
>> Joe Gordon wrote:<br>
</span><span class="">>> > I cannot speak for all projects, but at least in Nova you have to be a<br>
>> > nova-core to be part of nova-drivers.<br>
>><br>
>> And would you describe that as a good thing ? If John Garbutt is so deep<br>
>> into release liaison work that he can't sustain a review rate suitable<br>
>> to remain a core reviewer, would you have him removed from the<br>
>> "maintainers" group ? If someone steps up and works full-time on<br>
>> triaging bugs in Nova (and can't commit to do enough reviews as a<br>
>> result), would you exclude that person from your "maintainers" group ?<br>
><br>
> I want to empower that person and recognize them in some semi formal<br>
> capacity and make sure they have all the correct permissions.<br>
><br>
> I do not want a single flat 'maintainers' group, I think we need a<br>
> hierarchical notion of maintainers, where different people can end up<br>
> with very different responsibilities (and ACLs -- but that is a<br>
> implementation detail).<br>
<br>
</span>OK, so I probably misread your proposal[1]. My understanding was you<br>
wanted a single flat "maintainers" group that would purely replace "core<br>
reviewers", keep the same rights and just add duties to the<br>
already-existing reviewing duties.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/163660/" target="_blank">https://review.openstack.org/#/c/163660/</a></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Since I thought project leadership needs to be expressed in a much more<br>
diverse and inclusive way (and explicitly not tied to +2 rights), I<br>
opposed such simple renaming.<br>
<br>
>From what you're saying now your objective is the same as mine. I'm not<br>
sure the maintainers group needs to be purely hierarchical (I think I'd<br></blockquote><div><br></div><div>Hierarchical, in the sense of subsystem maintainers. Not all duties would have to be that way though. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
prefer it to be a set of duties with no hierarchy between them), but I<br>
agree that:<br>
<br>
- today core reviewers are the only visible project duty, and we need to<br>
expose and reward all the others, as separate attributes</blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- we could use a blanket term ("maintainers" ?) to describe the people<br>
holding one or more of those attributes.<br></blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
>> OpenStack governance mandates that core developers are ultimately the<br>
>> PTL's choice. Since the PTL is regularly elected by all contributors,<br>
>> that prevents aristocracy.<br>
><br>
> Can you site your source for this? Because the earliest reference to<br>
> 'Core Developer' (what you are calling core reviewer -- even though that<br>
> is not the original name) that I could find says nothing about it<br>
> ultimately being the PTLs choice.<br>
<br>
</span>PTLs have (and always had) ultimate say over their project matters. That<br>
includes how to select core reviewers (or how reviews should be<br>
performed). A lot of projects let their PTL directly determine who<br>
should (and should no longer) be on the core list.<br>
<br>
> <a href="https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess" target="_blank">https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess</a><br>
<br>
Now it's true that very early on, a lot of PTLs adopted a more "open"<br>
process to help in that selection. That doesn't mean they can't bypass<br>
the process.<br>
<br>
Personally I think that the apparently "open" process for core selection<br>
just resulted in reinforcing the aristocracy. This is why I encourage<br>
PTLs to own the content of core reviewing teams more directly.<br>
<span class=""><br>
>> However in some projects, core reviewers have to be approved by existing<br>
>> core reviewers. That is an aristocracy. In those projects, if you<br>
><br>
> Which projects do it differently?<br>
<br>
</span>The Swift PTL always just announced additions. I seem to remember<br>
TripleO under Robert Collins directly adding members. Also Nova under<br>
Russell Bryant removed inactive members without asking for an existing<br>
core members poll. (and that is all good). That said, I agree with you<br>
that most projects copied the "existing cores must agree" rule.<br></blockquote><div><br></div><div>It sounds like writing down this aspect of the PTL powers may be something worth writing down in the governance repo somewhere?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> So this is where you loose me. Has there ever been a case of a project's<br>
> PTL adding/removing people from the core team where the PTL goes against<br>
> the majority of the core developers? You say that an early (unwritten?)<br>
> goal of the system we have is to prevent 'aristocracy,' but all I see is<br>
> 'aristocracy'.<br>
<br>
</span>Obviously the PTL would only overrule the majority of his core reviewers<br>
in extreme cases. Imagine this extreme case: core reviewers in a project<br>
have become a pure aristocracy, nobody can get in anymore, fresh ideas<br>
and code are systematically rejected. There is a divide between<br></blockquote><div><br></div><div><div>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.</div></div><div><br></div><div>If this did happen there is a better safety valve IMHO, the fork.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
contributors to the project (doing the work) and core reviewers. Project<br>
is completely blocked. At the next election, a PTL candidate campaigns<br>
on fixing this by dramatically changing the core team. Contributors<br>
rally to that candidacy, candidate is elected. Once elected, the PTL can<br>
fix the core team without asking the existing aristocracy blessing.<br>
<br>
Now I agree that it's a governance safety valve, designed to solve a<br>
mostly theoretical case. But sometimes having a "bucket stops here" rule<br>
is sufficient to prevent conflict. For example conflicts between two<br>
projects can be escalated to the TC for final resolution. In effect,<br>
that never happens: said projects usually solve the issue between<br>
themselves rather than ask the TC to arbitrate. The same effect applies<br>
here: saying "the PTL has ultimate say anyway" usually prevents a total<br>
disconnect between the contributors and the core reviewers, because<br>
everyone knows there is a safety valve. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> [...]<br>
<span class="">> So, let me take a step back here. I would like to see at least 2 to 3x<br>
> more people in a given project to feel empowered and have badges, and<br>
> make it possible for part time upstream developers to hold some of said<br>
> badges. It sounds like you more or less agree with that goal. So how do<br>
> you propose we get there?<br>
<br>
</span>Define roles (separate from "core reviewing") that are useful tasks, and<br>
let people hold those roles. For example we introduced this cycle the<br>
concept of liaisons -- this is incredibly important work, and I'd like<br>
the people who hold those roles to be more widely recognized. </blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Now the problem is how we give more recognition to those people. I've<br>
been trying to popularize the use of the "CPL" acronym (cross-project<br>
liaisons) as a key part of the project leadership (just below the PTL).<br>
Maybe we need a blanket term ("maintainers" ?) to regroup all those roles ?<br>
<span class=""><br>
> Because having 15 core reviewers for all of nova is just not cutting it.<br>
<br>
</span>So I think that's a separate issue. Lack of core reviewers in Nova is<br>
because the domain you have to have expertise on is just too big. That<br>
means it is very hard to maintain the expertise and activity level to<br>
remain a core reviewer, and even harder to learn enough to become one. I<br>
fear the only solution there is to have separate core review teams<br>
responsible for smaller areas of code. But that is a separate thread imho.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>