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. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp