<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <span dir="ltr"><<a href="mailto:corvus@inaugust.com" target="_blank">corvus@inaugust.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> writes:<br>
<br>
> From what I understand, the intended projects for the incubator can't<br>
> operate without neutron because they are just extensions/plugins/drivers.<br>
<br>
</div>I could have phrased that better.  What I meant was that they could<br>
operate without being actually in the Neutron repo, not that they could<br>
not operate without Neutron itself.<br>
<br>
The proposal for the incubator is that extensions be developed outside<br>
of the Neutron repo.  My proposed refinement is that they stay outside<br>
of the Neutron repo.  They live their entire lives as extension modules<br>
in separate projects.<br>
<div class=""><br>
> For example, if the DVR modifications to the reference reference L3 plugin<br>
> weren't already being developed in the tree, DVR could have been developed<br>
> in the incubator and then merged into Neutron once the bugs were ironed out<br>
> so a huge string of Gerrit patches didn't need to be tracked. If that had<br>
> happened, would it make sense to keep the L3 plugin as a completely<br>
> separate project or merge it? I understand this is the approach the load<br>
> balancer folks took by making Octavia a separate project, but I think it<br>
> can still operate on its own, where the reference L3 plugin (and many of<br>
> the other incubator projects) are just classes that expect to be able to<br>
> make core Neutron calls.<br>
<br>
</div>The list of Juno/Kilo candidates doesn't seem to have projects that are<br>
quite so low-level.<br>
<br>
If a feature is going to become part of the neutron core, then it should<br>
be developed in the neutron repository.  If we need a place to land code<br>
that isn't master, it's actually far easier to just use a feature branch<br>
on the neutron repo.  Commits can land there as needed, master can be<br>
periodically merged into it, and when the feature is ready, the feature<br>
branch can be merged into master.<br></blockquote><div><br></div><div>We have feature branches? How do we use them? I am not even sure if feature branches were evaluated as an option when the incubator was proposed.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think between those two options: incubate/spin-out components that are<br>
high-level enough not to have deep integration in the neutron core, and<br>
using feature branches for large experimental changes to the core<br>
itself, we can handle the problems the incubator repo is intended to<br>
address.<br>
<div class="HOEnZb"><div class="h5"><br>
-Jim<br>
<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>
</div></div></blockquote></div><br></div></div>