Open Stack

On Wed, Aug 27, 2014, at 04:05 PM, Joe Gordon wrote:
> 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.
> 
We do. I thought there was a wiki article on how they work but I can't
find it. Maybe someone else can link it here.

The basics are someone creates a branch called feature/foo via the
Gerrit GUI [0], for OpenStack projects members of the release managers
group can do this and for other projects we can update ACLs to give the
-release group permissions to do this (and infra can always do it). Then
you push code against that branch `git review feature/foo` (it will push
to the correct branch if you edit the .gitreview file on that branch).

Periodically you will want to merge master back into your feature
branches so that you don't lag too far behind and when the feature is
ready you merge it back into master. You need special perms to push
merge commits to Gerrit so that is something that may need to be worked
out depending on how the existing ACLs look for a project. The swift
devs recently did this for their EC feature and may have more feedback.

[0]
https://review.openstack.org/#/admin/projects/openstack/neutron,branches
> 
> >
> > 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
> >
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev