<div dir="ltr">Quoting Stefano from a different thread [0]:<div><br></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">
<span style="font-family:arial,sans-serif;font-size:13px">The rationale for the separate repository is that Neutron's code needs a</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">lot of love for the *existing* codebase, before new features can be</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">added (and before core team can accept more responsibilities for it).</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">But progress is unstoppable: new features are being proposed every cycle</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">and reviewers bandwidth is not infinite.</span></blockquote><div><br></div><div>The long term purpose of the incubator should be to gather all the big new features that may require fast iteration before becoming stable and being eventually merged into the main tree. This is especially important for "core" new features, that may have a higher impact on Neutron's stability. <br>
</div><div>A great example was made by Kevin with DVR.</div><div><br></div><div><span>[0] <a class="" href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044224.html">http://lists.openstack.org/pipermail/openstack-dev/2014-August/044224.html</a> </span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 1:32 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@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>I agree that components isolated to one service or something along those lines where there is a clear plugin point in Neutron, it might make sense to separate them permanently. However, at that point why even bother with the Neutron incubator when a new project can be started?</div>
<div><br></div><div>The feature branch idea sounds interesting for the one-time big experimental changes. Are there any other projects that do this right now?<br></div></div><div class="gmail_extra"><div><div class="h5">
<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>Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">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><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>
<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><div><br>
-Jim<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Kevin Benton</div>
</font></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>