<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 June 2015 at 07:12, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand <span dir="ltr"><<a href="mailto:iwienand@redhat.com" target="_blank">iwienand@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 06/03/2015 07:24 AM, Boris Pavlovic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Really it's hard to find cores that understand whole project, but<br>
it's quite simple to find people that can maintain subsystems of<br>
project.<br>
</blockquote>
<br></span>
We are made wise not by the recollection of our past, but by the<br>
responsibility for our future.<br>
- George Bernard Shaw<br>
<br>
Less authorities, mini-kingdoms and<br>
turing-complete-rule-based-gerrit-subtree-git-commit-enforcement; more empowerment of responsible developers and building trust.<span><font color="#888888"><br>
<br>
-i</font></span><div><div><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></div><div class="gmail_extra"><div style="font-family:monospace,monospace">All of the debate about the technical feasibility, additional repos aside, the one question I always raise when topics like this come up is "how does that really solve the problem". In other words, there's still a finite number of folks that dedicate the time to be "subject matter experts" and do the reviews.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Maybe this will help, I don't know. But I have the same argument as I made in my spec to remove drivers from Cinder altogether, creating "another repo" and moving things around just creates more overhead and does little to address the lack of review resources.</div></div></div></blockquote><div><br></div><div>In the neutron project we do not have yet enough data points to assess impact of driver/plugin split on review turnaround. On the one hand it seems that there is no statistically significant improvement in review times for the "core" part, but on the other hand average review times for plugin/driver code have improved a lot. So I reckon that there's been a clear advantage on this front. There is always a flip of the coin, of course: plugin maintainers have to do extra work to chase changes in openstack/neutron.</div><div><br></div><div>However, this is a bit out of scope for this thread. I'd say that splitting out a project in several repositories is an option, but not always the right one. In the case of neutron plugins and drivers, it made sense because there is a stable-ish interface between the core system and the plugin, and because there's usually little overlap of responsibilities.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">I understand you're not proposing new repos Boris, although it was mentioned in this thread.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">I do think that we could probably try and do something like growing the Lieutenant model that the Neutron team is hammering out. Not sure... but seems like a good start; again assuming there are enough qualified/interested Lieutenants. I'm not sure, but that's kind of how I interpreted your proposal but one additional step of ACL's; is that accurate?</div></div></div></blockquote><div><br></div><div>While I cannot answer for Boris, my opinion is that the lieutenant system actually tries to provide a "social" solution to the problem, where as ACLs are a technical solution. I personally think that the belief that there's always a tool to fix any problem is a giant unicorn - as Robert put it there's no technical solution to a social problem. A technical solution would probably end up bringing more process, more bureaucracy, and therefore more annoyance... but I'm digressing.</div><div><br></div><div>In my opinion the lieutenant system is an attempt to build networks of trusted and responsible developers who share interest (more or less vested) and knowledge on a specific subsystem of a project. If implemented correctly, it will ensure those networks are small enough so that trust can be achieved in a simple way.</div><div>I'd rather rely on trust and common sense than on a set of ACLs that probably at some point will get in the way and be more a hindrance than a help.</div><div><br></div><div>Salvatore</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Thanks,</div><div style="font-family:monospace,monospace">John</div><br></div></div>
<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>
<br></blockquote></div><br></div></div>