openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

I 150% agree that is a red-herring, that's why I wonder what it really offers besides a 'façade' and/or the feeling that what u are using isn't a package, when in concept it really is, except now u have lost all the benefits of using version numbers, having dependency versions (with history) and all that, so the 'façade' seems pretty weak imho.

+1 for library that follows the normal packaging methodology

On 7/3/12 11:59 AM, "Gabriel Hurley" <Gabriel.Hurley@xxxxxxxxxx> 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

> -----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



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp