<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 24, 2014 at 5:09 PM, Luke Gorrie <span dir="ltr"><<a href="mailto:luke@tail-f.com" target="_blank">luke@tail-f.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 class="">On 21 August 2014 12:12, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="">
<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>Let the ones that are primarily interested in<br>
</div>
good quality of that code (vendors) to drive development. And if some<br>
plugins become garbage, it's bad news for specific vendors; if neutron<br>
screws because of lack of concentration on core features and open<br>
source plugins, everyone is doomed.<br></blockquote><div><br></div></div><div>Completely agree with this sentiment. Is there a crisp distinction between a "vendor" plugin and an "open source" plugin though?</div>
</div></div></div></blockquote><div><br></div><div>This topic is interesting: should all opensource backend drivers be put into the tree? </div><div><br></div><div>But as Kyle has mentioned earlier, Incubator is not the place to discuss in-tree / out-tree for 3rd vs. built-in drivers, but the place to bake newly introduced API and resource model for fast iteration, so I'll forward this topic in another thread.</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 class="gmail_quote">
<div><br></div><div>The Snabb NFV (<a href="http://snabb.co/nfv.html" target="_blank">http://snabb.co/nfv.html</a>) driver superficially looks like a vendor plugin but is actually completely open source. The development is driven by end-user organisations who want to make the standard upstream Neutron support their NFV use cases.</div>

<div><br></div><div>We are looking for a good way to engage with the upstream community. In this cycle we have found kindred spirits in the NFV subteam., but we did not find a good way to engage with Neutron upstream (see <a href="https://review.openstack.org/#/c/116476/" target="_blank">https://review.openstack.org/#/c/116476/</a>). It would be wonderful if there is a suitable process available for us to use in Kilo e.g. incubation.</div>

<div><br></div><div>Cheers,<br></div><div>-Luke</div><div><br></div><div><br></div></div></div></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></div>