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?
The feature branch idea sounds interesting for the one-time big experimental changes. Are there any other projects that do this right now? On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <cor...@inaugust.com> wrote: > Kevin Benton <blak...@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. > > 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
