<div dir="ltr">Guys, <div><br></div><div>I will try to summarize all questions and reply on them: </div><div><br></div><div><b>- Why not splitting repo/plugins?</b></div><div><br></div><div> I don't want to make "architectural" decisions based on "social" or </div><div> "not enough good tool for review" issues. </div><div><br></div><div> If we take a look at OpenStack that was splited many times: Glance, Cinder, ...</div><div> we will see that there is a log of code duplication that can't be removed even after </div><div> two or even more years of oslo effort. As well it produce such issues like syncing </div><div> requirements, requirements in such large bash script like devstack, </div><div> there is not std installator, it's quite hard to manage and test it and so on.. </div><div><br></div><div> That's why I don't think that splitting repo is good "architecture" decision - it makes </div><div> simple things complicated...</div><div><br></div><div><br></div><div><b>- Why not just trust people</b></div><div><br></div><div>People get tired and make mistakes (very often). </div><div>That's why we have blocking CI system that checks patches, </div><div>That's why we have rule 2 cores / review (sometimes even 3,4,5...)... </div><div><br></div><div>In ideal work Lieutenants model will work out of the box. In real life all checks like: </div><div>person X today has permission to do Y operation should be checked automatically. </div><div><br></div><div>This is exactly what I am proposing.</div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 8:42 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><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></span><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><span class=""><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></span><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><span class="">
<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></span></blockquote></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>