openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

On Tue, 2012-07-03 at 18:59 +0000, 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.

A library with an unstable upgrade path isn't a library.

Projects pegging to different versions of the same library is evil for
distributions.

Example:

  horizon pegs to openstack-common=0.2
  nova pegs to openstack-common=0.6
  glance pegs to openstack-common=0.5

We release Folsom and tell distributors that they need to package
versions 0.2, 0.5 and 0.6 of openstack-common?

No - the openstack-common library, when we start releasing it, will not
have an unstable upgrade path because it will not have unstable 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.

If an individual APIs isn't stable, it's referred to as being in
"incubation". That's all the term means in this context.

> Anyhow, I'm +1 on turning it into a real library of its own, as a
> couple people suggested already.

Superb. No-one is -1 on releasing it as a library. It's been the
documented plan from the beginning.

Cynically, I find people getting indignant about openstack-common's
update.py process quite hilarious.

Within OpenStack, there's been an ongoing culture of copying-and-pasting
code willy nilly between projects without any heed to the long-term
maintenance consequences. The openstack-common project is about paying
back some of that technical debt.

While we're preparing to do a first release of an openstack-common
library with stable APIs, we have this "managed copy-and-paste" process.
Yes, it sucks. But it sucks far less than the copy-and-pasting the
project has been doing all along.

Next time someone flames this "managed copy-and-paste" thing, I'm going
to dig through the git history and find examples of them copying and
pasting code between projects :-)

Oh, and lest anyone claim that the project is maturing and moving away
from the bad old days of copy-and-paste ... take a look at what we've
just done with Cinder. That's our most epic copy-and-paste yet!

Mark.