Open Stack

On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <corvus at inaugust.com>
wrote:

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

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.


>
> I think between those two options: incubate/spin-out components that are
> high-level enough not to have deep integration in the neutron core, and
> using feature branches for large experimental changes to the core
> itself, we can handle the problems the incubator repo is intended to
> address.
>
> -Jim
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/07e1ca70/attachment.html>