openstack team mailing list archive

[Andrew Bogott <abogott@xxxxxxxxxxxxx>]

On 7/3/12 5:47 PM, Eric Windisch wrote:
> git submodules don't have to be linked to the head of a branch. 
> Instead of double-commiting (for every commit), we can do a single 
> commit in each project to change the git reference of the submodule. 
> This would not be too far from the existing behavior, except that it 
> would minimize the double commits.
Oh, I guess I left out an important part of my vision, which is that 
there would be a commit hook in common which moves the submodule 
reference in the parent projects anytime a patch is merged in common.  
So, in short: once a patch passed review for inclusion in common, that 
patch would automatically go live in all other project heads simultaneously.

> --
> Eric Windisch
>
> On Tuesday, July 3, 2012 at 15:47 PM, Andrew Bogott wrote:
>
> > On 7/3/12 1:59 PM, Gabriel Hurley wrote:
> > > The notion that copying code is any protection against APIs that may 
> > > change is a red herring. It's the exact same effect as pegging a 
> > > version of a dependency (whether it's a commit hash or a real 
> > > version number), except now you have code duplication. An unstable 
> > > upgrade path is an unstable upgrade path, and copying the code into 
> > > the project doesn't alleviate the pain for the project if the 
> > > upstream library decides to change its APIs.
> > >
> > > Also, we're really calling something used by more or less all the 
> > > core projects "incubated"? ;-) Seems like it's past the 
> > > proof-of-concept phase now, at least for many parts of common. 
> > > Questions of API stability are an issue unto themselves.
> > >
> > > Anyhow, I'm +1 on turning it into a real library of its own, as a 
> > > couple people suggested already.
> > >
> > > - Gabriel
> >
> > I feel like I should speak up since I started this fight in the first
> > place :)
> >
> > Like most people in this thread, I too long for an end to the weird
> > double-commit process that we're using now. So I'm happy to set aside
> > my original Best Practices proposal until there's some consensus
> > regarding how much longer we're going to use that process. Presumably
> > opinions about how to handle merge-from-common commits will vary in the
> > meantime, but that's something we can live with.
> >
> > In terms of promoting common into a real project, though, I want to
> > raise another option that's guaranteed to be unpopular: We make
> > openstack-common a git-submodule that is automatically checked out
> > within the directory tree of each other project. Then each commit to
> > common would need to be gated by the full set of tests on every project
> > that includes common.
> >
> > I haven't thought deeply about the pros and cons of code submodule vs.
> > python project, but I want to bring up the option because it's the
> > system that I'm the most familiar with, and one that's been discussed a
> > bit off and on.
> >
> > -Andrew
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx 
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > More help : https://help.launchpad.net/ListHelp