openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

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

> -----Original Message-----
> From: openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-
> bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> James E. Blair
> Sent: Tuesday, July 03, 2012 6:56 AM
> To: andrewbogott@xxxxxxxxx
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] best practices for merging common into specific
> projects
> 
> Andrew Bogott <abogott@xxxxxxxxxxxxx> writes:
> 
> > I.      As soon as a patch drops into common, the patch author should
> > submit merge-from-common patches to all affected projects.
> >     A.  (This should really be done by a bot, but that's not going to
> > happen overnight)
> 
> Actually, I think with our current level of tooling, we can have Jenkins do this
> (run by Zuul as a post-merge job on openstack-common).
> 
> I very much believe that the long-term goal should be to make openstack-
> common a library -- so nothing I say here should be construed against that.
> But as long as it's in an incubation phase, if doing something like this would
> help move things along, we can certainly implement it, and fairly easily.
> 
> Note that a naive implementation might generate quite a bit of review spam
> if several small changes land to openstack-common (there would then be
> changes*projects number of reviews in gerrit).  We have some code laying
> around which might be useful here that looks for an existing open change
> and amends it; at least that would let us have at most only one open merge-
> from-common-change per-project.
> 
> Okay, that's all on that; I don't want to derail the main conversation, and I'd
> much rather it just be a library if we're close to being ready for that.
> 
> -Jim
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp