Open Stack

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