<div dir="ltr"><div>Gary, you are still miss the point of this proposal. Please see my comments in review. We are not forcing things out of tree, we are thinning them. The text you quoted in the review makes that clear. We will look at further decomposing ML2 post Kilo, but we have to be realistic with what we can accomplish during Kilo.<br><br></div>Find me on IRC Monday morning and we can discuss further if you still have questions and concerns.<br><br>Thanks!<br>Kyle<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi,</div>
<div>I have raised my concerns on the proposal. I think that all plugins should be treated on an equal footing. My main concern is having the ML2 plugin in tree whilst the others will be moved out of tree will be problematic. I think that the model will be
complete if the ML2 was also out of tree. This will help crystalize the idea and make sure that the model works correctly.</div>
<div>Thanks</div>
<div>Gary</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>"Armando M." <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Saturday, December 6, 2014 at 1:04 AM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, "<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [Neutron] Core/Vendor code decomposition<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div>
<div dir="ltr">Hi folks,
<div><br>
</div>
<div>For a few weeks now the Neutron team has worked tirelessly on [1].</div>
<div><br>
</div>
<div>This initiative stems from the fact that as the project matures, evolution of processes and contribution guidelines need to evolve with it. This is to ensure that the project can keep on thriving in order to meet the needs of an ever growing community.</div>
<div><br>
</div>
<div>The effort of documenting intentions, and fleshing out the various details of the proposal is about to reach an end, and we'll soon kick the tires to put the proposal into practice. Since the spec has grown pretty big, I'll try to capture the tl;dr below.</div>
<div><br>
</div>
<div>If you have any comment please do not hesitate to raise them here and/or reach out to us.</div>
<div><br>
</div>
<div>tl;dr >>></div>
<div><br>
</div>
<div>From the Kilo release, we'll initiate a set of steps to change the following areas:</div>
<div>
<ul>
<li>Code structure: every plugin or driver that exists or wants to exist as part of Neutron project is decomposed in an slim vendor integration (which lives in the Neutron repo), plus a bulkier vendor library (which lives in an independent publicly available
repo);<br>
</li><li>Contribution process: this extends to the following aspects:
<ul>
<li>Design and Development: the process is largely unchanged for the part that pertains the vendor integration; the maintainer team is fully auto governed for the design and development of the vendor library;</li><li>Testing and Continuous Integration: maintainers will be required to support their vendor integration with 3rd CI testing; the requirements for 3rd CI testing are largely unchanged;</li><li>Defect management: the process is largely unchanged, issues affecting the vendor library can be tracked with whichever tool/process the maintainer see fit. In cases where vendor library fixes need to be reflected in the vendor integration, the usual OpenStack
defect management apply. </li><li>Documentation: there will be some changes to the way plugins and drivers are documented with the intention of promoting discoverability of the integrated solutions.</li></ul>
</li><li>Adoption and transition plan: we strongly advise maintainers to stay abreast of the developments of this effort, as their code, their CI, etc will be affected. The core team will provide guidelines and support throughout this cycle the ensure a smooth transition.</li></ul>
<div>To learn more, please refer to [1].</div>
<div><br>
</div>
</div>
<div>Many thanks,</div>
<div>Armando</div>
<div><br>
</div>
<div>[1] <a href="https://review.openstack.org/#/c/134680" target="_blank">https://review.openstack.org/#/c/134680</a></div>
</div>
</div>
</div>
</div></div></span>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>