<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 7/3/12 5:47 PM, Eric Windisch wrote:
<blockquote
cite="mid:88424D5CAF6940A89B58DC95C26D3E14@cloudscaling.com"
type="cite">
<div><span style="font-size: 12px;">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.</span> </div>
<div>
<div><br>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:88424D5CAF6940A89B58DC95C26D3E14@cloudscaling.com"
type="cite">
<div>-- <br>
Eric Windisch
<div><br>
</div>
</div>
<p style="color: #A0A0A8;">On Tuesday, July 3, 2012 at 15:47 PM,
Andrew Bogott wrote:</p>
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span>
<div>
<div>
<div>On 7/3/12 1:59 PM, Gabriel Hurley wrote:</div>
<blockquote type="cite">
<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Anyhow, I'm +1 on turning it into a real library
of its own, as a couple people suggested already.</div>
<div><br>
</div>
<div> - Gabriel</div>
</div>
</blockquote>
<div><br>
</div>
<div>I feel like I should speak up since I started this
fight in the first </div>
<div>place :)</div>
<div><br>
</div>
<div>Like most people in this thread, I too long for an
end to the weird </div>
<div>double-commit process that we're using now. So I'm
happy to set aside </div>
<div>my original Best Practices proposal until there's
some consensus </div>
<div>regarding how much longer we're going to use that
process. Presumably </div>
<div>opinions about how to handle merge-from-common
commits will vary in the </div>
<div>meantime, but that's something we can live with.</div>
<div><br>
</div>
<div>In terms of promoting common into a real project,
though, I want to </div>
<div>raise another option that's guaranteed to be
unpopular: We make </div>
<div>openstack-common a git-submodule that is
automatically checked out </div>
<div>within the directory tree of each other project. Then
each commit to </div>
<div>common would need to be gated by the full set of
tests on every project </div>
<div>that includes common.</div>
<div><br>
</div>
<div>I haven't thought deeply about the pros and cons of
code submodule vs. </div>
<div>python project, but I want to bring up the option
because it's the </div>
<div>system that I'm the most familiar with, and one
that's been discussed a </div>
<div>bit off and on.</div>
<div><br>
</div>
<div>-Andrew</div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></div>
<div>Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></div>
<div>Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></div>
<div>More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></div>
</div>
</div>
</span> </blockquote>
<div> <br>
</div>
</blockquote>
<br>
</body>
</html>