<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 6:55 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.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 dir="ltr"><div><div>As part of the team's continuing effort to scale development in Neutron, we have officially merged the Lieutenant patch [1]. As the codebase continues to grow, this is an attempt to scale the code review load so we can grow new core reviewers while maintaining the model of trust required to successfully run the project. Please note we've selected some initial horizontal Lieutenant positions (you can see them here [2]). This could change as we experiment with things, but for now we've tried to select areas which make the most sense immediately.<br><br></div><div>Thanks to all who contributed feedback on the patchset which enabled this. As with everything, we'll experiment and reevaluate where things are throughout Liberty and do a postmortem at the next Summit to understand if we need to adopt the model.<br></div><div><br></div></div></div></blockquote><div><br></div><div>Great job, I look forward to seeing this model adopted elsewhere.</div><div><br></div><div>This sounds a lot like another large scale project we all know of</div><div><br></div><div><br></div><div>".... has long since grown to a size where no single</div><div>developer could possibly inspect and select every patch unassisted.  The</div><div>way the ... developers have addressed this growth is through the use of</div><div>a lieutenant system built around a chain of trust.</div><div><br></div><div>The ... code base is logically broken down into a set of subsystems:</div><div>...  Most subsystems have a designated maintainer, a developer<br></div><div>who has overall responsibility for the code within that subsystem.  These</div><div>subsystem maintainers are the gatekeepers (in a loose way) for the portion</div><div>of the .... they manage."</div><div><br></div><div>I wonder if we can adopt the rolling development model as well?</div><div><br></div><div><a href="https://www.kernel.org/doc/Documentation/development-process/2.Process">https://www.kernel.org/doc/Documentation/development-process/2.Process</a><br></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"><div dir="ltr"><div><div></div>Thanks,<br></div>Kyle<br><div><div><div><br>[1] <a href="https://review.openstack.org/#/c/178846/" target="_blank">https://review.openstack.org/#/c/178846/</a><br>[2] <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.html</a><br></div></div></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>