<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 June 2015 at 23:59, Ian Cordasco <span dir="ltr"><<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</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"><div class=""><div class="h5"><br>
<br>
On 6/2/15, 16:24, "Boris Pavlovic" <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>> wrote:<br>
<br>
>Hi stackers,<br>
><br>
><br>
>Issue<br>
>-------<br>
><br>
><br>
>Projects are becoming bigger and bigger overtime.<br>
>More and more people would like to contribute code and usually core<br>
>reviewers<br>
>team can't scale enough. It's very hard to find people that understand<br>
>full project and have enough time to do code reviews. As a result team is<br>
>very small under heavy load and many maintainers just get burned out.<br>
><br>
><br>
>We have to solve this issue to move forward.<br>
><br>
><br>
><br>
><br>
>Idea<br>
>------<br>
><br>
><br>
>Let's introduce subsystems cores.<br>
><br>
><br>
>Really it's hard to find cores that understand whole project, but it's<br>
>quite simple to find people that can maintain subsystems of project.<br>
><br>
><br>
><br>
><br>
>How To<br>
>-----------<br>
><br>
><br>
>Gerrit is not so simple as it looks and it has really neat features ;)<br>
><br>
><br>
>For example we can write own rules about who can put +2 and merge patch<br>
>based on changes files.<br>
><br>
><br>
>We can make special "subdirectory core" ACL group.<br>
>People from such ACL group will be able to merge changes that touch only<br>
>files from some specific subdirs.<br>
><br>
><br>
>As a result with proper organization of directories in project we can<br>
>scale up review process without losing quality.<br>
><br>
><br>
><br>
><br>
>Thoughts?<br>
><br>
><br>
><br>
><br>
>Best regards,<br>
>Boris Pavlovic<br>
<br>
</div></div>I like this very much. I recall there was a session at the summit about<br>
this that Thierry and Kyle led. </blockquote><div><br></div><div>Indeed, and Kyle has already transformed that into facts [1]</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">If I recall correctly, the discussion<br>
mentioned that it wasn't (at this point in time) possible to use gerrit<br>
the way you describe it, but perhaps people were mistaken?<br></blockquote><div><br></div><div>I recall that too, and I also recall fungi stating the same thing back in Paris.</div><div>Gerrit doesn't really have a concept of subsystems, as far as I can understand; in theory gerrit could be changed to support this, but that's another discussion.</div><div>The networking community is currently adopting multiple repositories to this aim. This has worked very well for 3rd party plugins, and quite well for advanced services.</div><div>For the 'neutron' proper project, which is however large enough to identify multiple subsystems in it, the lieutenant mode described in [1] will be enforced with a bit of common sense - from what I gather. If you're a core for subsystem X, nominated by its lieutenant, you're not supposed to +/-2 patches that only marginally affect your subsystem or do not affect it at all.</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>
If we can do this exactly as you describe it, that would be awesome.</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">If<br>
there's a problem in limiting people to what files they can approve<br>
changes for, then an alteration might be that those people get +2 but not<br>
+W. This provides a signal to whomever has +W that the review is very much<br>
ready to be merged. Does that sound fair?<br></blockquote><div><br></div><div>neutron-specs adopts this approach (all cores can +2 but only a handful can +A).</div><div>I think it works, in the assumption of a lieutenant systems, but for projects with a large patch turnaround might constitute a bottleneck, especially when there are gate-breaking issues that need to be approved ASAP.</div><div>Generally speaking, I believe having 2 ties of cores (those with +A rights and those without) is an experiment worth doing. I don't think it creates an "elite" among developers; on the other hand, it gives SMEs a chance to have a greater impact.</div><div> </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">
<br>
Cheers,<br>
Ian<br>
<br></blockquote><div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/core-reviewers.rst">http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/core-reviewers.rst</a></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>
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>
</blockquote></div><br></div></div>