<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 3:14 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>
>>     My main objection to the model you propose is its binary nature. You<br>
>>     bundle "core reviewing" duties with "drivers" duties into a single<br>
>>     group. That simplification means that drivers have to be core reviewers,<br>
>>     and that core reviewers have to be drivers. Sure, a lot of core<br>
>>     reviewers are good candidates to become drivers. But I think bundling<br>
>>     the two concepts excludes a lot of interesting people from being a<br>
>>     "driver".<br>
><br>
> 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>
</span>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></blockquote><div><br></div><div>I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions.</div><div><br></div><div>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).   </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>
>>     If someone steps up and owns bug triaging in a project, that is very<br>
>>     interesting and I'd like that person to be part of the "drivers" group.<br>
><br>
> In our current model, not sure why they would need to be part of<br>
> drivers. the bug triage group is open to anyone.<br>
<br>
</span>I think we are talking past each other. I'm not saying bug triagers have<br></blockquote><div><br></div><div>It appears that we are talking past each other, at least we agree on something.</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">
to be drivers. I'm saying bug triagers should be *allowed* to<br>
potentially become drivers, even if they aren't core reviewers. That is<br>
including of all forms of project leadership.<br>
<br>
You are the one suggesting that maintainers and core reviewers are the<br>
same thing, and therefore asking that all maintainers/drivers have to be<br>
core reviewers, actively excluding non-reviewers from that project<br>
leadership class.<br>
<span class=""><br>
>>     Saying core reviewers and maintainers are the same thing, you basically<br>
</span><span class="">>>     exclude people from stepping up to the project leadership unless they<br>
>>     are code reviewers. I think that's a bad thing. We need more people<br>
>>     volunteering to own bug triaging and liaison work, not less.<br>
><br>
> I don't agree with this statement, I am not saying reviewing and<br>
> maintenance need to be tightly coupled.<br>
<br>
</span>You've been proposing to rename "core reviewers" to "maintainers". I'm<br>
not sure how that can be more tightly coupled...<br></blockquote><div><br></div><div>All core reviewers in our current model should be responsible for maintenance of the project, but not all maintainers need to be responsible for reviewing code anywhere in the project.</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>
> [...]<br>
<span class="">> I really want to know what you meant be 'no aristocracy' and the why<br>
> behind that.<br>
<br>
</span>Aristocracies are self-selecting, privileged groups. Aristocracies<br>
require that current group members agree on any new member addition,<br>
basically limiting the associated privilege to a caste. Aristocracies<br>
result in limited gene pool, tunnel vision and echo chamber effects.<br>
<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.</blockquote><div><br></div><div>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.</div><div><br></div><div><a href="https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess">https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess</a></div><div><br></div><div>Where is the current documentation 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>
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></blockquote><div><br></div><div>Which projects do it differently?</div><div><br></div><div>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'.</div><div><br></div><div>It sounds like if a goal was no aristocracy then we have miserably failed at that. But frankly I don't know to prevent what you call aristocracy.</div><div><br></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">
associate more rights and badges to core reviewing (like by renaming it<br>
"maintainer" and bundle "driver" responsibilities with it), I think you<br>
actually extend the aristocracy problem rather than reduce it.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Because having 15 core reviewers for all of nova is just not cutting it.</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">
<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>