Open Stack

On 7/3/12 5:47 PM, Eric Windisch wrote:
> git submodules don't have to be linked to the head of a branch. 
> Instead of double-commiting (for every commit), we can do a single 
> commit in each project to change the git reference of the submodule. 
> This would not be too far from the existing behavior, except that it 
> would minimize the double commits.
>
Oh, I guess I left out an important part of my vision, which is that 
there would be a commit hook in common which moves the submodule 
reference in the parent projects anytime a patch is merged in common.  
So, in short: once a patch passed review for inclusion in common, that 
patch would automatically go live in all other project heads simultaneously.

> -- 
> Eric Windisch
>
> On Tuesday, July 3, 2012 at 15:47 PM, Andrew Bogott wrote:
>
>> 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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> Post to : openstack at lists.launchpad.net 
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> More help : https://help.launchpad.net/ListHelp
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120703/5dc51fa8/attachment.html>