<div style="font-family: Helvetica; font-size: 13px; ">I agree, I think moving them into one of the package/dependency managers the Open Stack projects already use is the proper way to do this.<div><br></div><div>The current process of copying the "latest" seemingly un-versionable code around into the projects really bothered me when it just happened to Horizon for the JSON parser a few weeks ago, I wash;t too keen on approving that review and I'd like to get away from it if possible, even if done by a bot of some kind...</div></div>
<div><div><br></div><div><br></div><div>John Postlethwait</div><div>Nebula, Inc.</div><div>206-999-4492</div><div><br></div></div>
<p style="color: #A0A0A8;">On Monday, July 2, 2012 at 2:41 PM, Joshua Harlow wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>Re: [Openstack] best practices for merging common into specific projects</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">What about using openstack-common as a library instead of a preprocessor ‘inclusion’ system/copy code around system....??<br>
<br>
Maybe its time for that to happen? <br>
<br>
It always seemed sort of silly to me that files are being copied around to different projects like this, instead of referring to code in a common library package.<br>
<br>
On 7/2/12 12:16 PM, "Andrew Bogott" <<a href="abogott@wikimedia.org">abogott@wikimedia.org</a>> wrote:<br>
<br>
</span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"> Having spent some time last week writing code for openstack-common,<br>
and having spent yet more time trying to get those changes into Nova, I<br>
think it would be useful to define some best practices when crossing the<br>
boundary between common and other openstack projects.<br>
<br>
Background:<br>
<br>
The openstack-common project is subject to a standard code-review<br>
process (and, soon, will also have Jenkins testing gates.) Sadly,<br>
patches that are merged into openstack-common are essentially orphans. <br>
Bringing those changes into actual use requires yet another step, a<br>
'merge from common' patch where the code changes in common are copied<br>
into a specific project (e.g. nova.)<br>
Merge-from-common patches are generated via an automated process. <br>
Specific projects express dependencies on specific common components via<br>
a config file, e.g. 'nova/openstack-common.conf'. The actual file copy<br>
is performed by 'openstack-common/update.py,' and its behavior is<br>
governed by the appropriate openstack-common.conf file.<br>
<br>
Questions:<br>
<br>
When should changes from common be merged into other projects?<br>
What should a 'merge-from-common' patch look like?<br>
What code-review standards should core committers observe when<br>
reviewing merge-from-common patches?<br>
<br>
Proposals:<br>
<br>
I. As soon as a patch drops into common, the patch author should<br>
submit merge-from-common patches to all affected projects.<br>
A. (This should really be done by a bot, but that's not going to<br>
happen overnight)<br>
<br>
II. In the event that I. is not observed, merge-from-common patches<br>
will contain bits from multiple precursor patches. That is not only OK,<br>
but encouraged.<br>
A. Keeping projects in sync with common is important!<br>
B. Asking producers of merge-from-common patches to understand the<br>
full diff will discourage the generation of such merges.<br>
<br>
III. Merge-from-common patches should be the product of a single<br>
unedited run of update.py.<br>
A. If a merge-from-common patch breaks pep8 or a test in nova,<br>
don't fix the patch; fix the code in common.<br>
<br>
IV. Merge-from-common patches are 'presumed justified'. That means:<br>
A. Reviewers of merge-from-common patches should consider test<br>
failures and pep8 breakages, and obvious functional problems.<br>
B. Reviewers of merge-from-common patches should not consider the<br>
usefulness, design, etc. of merge-from-common patches. Such concerns<br>
need to be handled within the common review process.<br>
C. Merges from common should get reviewed early and approved<br>
readily in order to avoid project divergence<br>
<br>
V. Changes to openstack-common.conf are a special case.<br>
A. Patches with openstack-common.conf changes should include the<br>
relevant merge-from-common changes.<br>
B. Such patches should /not/ include any other merge-from-common<br>
changes.<br>
C. Such patches should not only include the common merges, but<br>
should also include whatever code changes make use of the new merge.<br>
D. Such patches require the same justification and scrutiny as any<br>
other standard project patch.<br>
<br>
Please discuss! If we're able to reach general agreement about this<br>
process, I will document the process in the openstack-common HACKING<br>
guidelines.<br>
<br>
-Andrew<br>
<br>
<br>
<br>
<br>
On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:<br>
> I did that before seeing this patch. However, I think I prefer what I pushed since it's individual updates explaining what they update instead of a blanket "update everything" commit.<br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
<br>
</span></font></blockquote></div><div><div>_______________________________________________</div><div>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></div><div>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>