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 OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev