Open Stack

On Wed, Aug 27, 2014, at 03:52 PM, Ivar Lazzaro wrote:
> Quoting Stefano from a different thread [0]:
> 
> The rationale for the separate repository is that Neutron's code needs a
> > lot of love for the *existing* codebase, before new features can be
> > added (and before core team can accept more responsibilities for it).
> > But progress is unstoppable: new features are being proposed every cycle
> > and reviewers bandwidth is not infinite.
> 
> 
> 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.
> A great example was made by Kevin with DVR.
>
The issue that Jim was trying to point out is that 'being eventually
merged into the main tree' is not something you can just do. It is
extremely costly to merge two repos together in this fashion and we
should avoid it at all costs. Feature branches make this relatively
cheap and should probably be considered instead.
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044224.html
> 
> 
> On Wed, Aug 27, 2014 at 1:32 PM, Kevin Benton <blak111 at gmail.com> wrote:
> 
> > 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 <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.
> >>
> >> 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
> >>
> >
> >
> >
> > --
> > Kevin Benton
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev