atom feed48 messages in net.launchpad.lists.openstack[Openstack] best practices for mergin...
FromSent OnAttachments
Andrew BogottJul 2, 2012 12:16 pm 
Russell BryantJul 2, 2012 12:26 pm 
Joshua HarlowJul 2, 2012 2:41 pm 
Joshua HarlowJul 2, 2012 2:54 pm 
Gabriel HurleyJul 2, 2012 3:18 pm 
John PostlethwaitJul 2, 2012 4:42 pm 
Christopher B FerrisJul 2, 2012 5:41 pm 
Thierry CarrezJul 3, 2012 2:31 am 
Thierry CarrezJul 3, 2012 2:34 am 
Doug HellmannJul 3, 2012 5:37 am 
James E. BlairJul 3, 2012 6:55 am 
Joshua HarlowJul 3, 2012 10:46 am 
Dan PrinceJul 3, 2012 10:59 am 
Gabriel HurleyJul 3, 2012 11:59 am 
Andrew BogottJul 3, 2012 12:47 pm 
Joshua HarlowJul 3, 2012 2:09 pm 
James E. BlairJul 3, 2012 2:54 pm 
Eric WindischJul 3, 2012 3:47 pm 
Andrew BogottJul 3, 2012 3:54 pm 
Gabriel HurleyJul 3, 2012 4:53 pm 
Timothy DalyJul 3, 2012 5:27 pm 
Monty TaylorJul 3, 2012 6:17 pm 
Thierry CarrezJul 4, 2012 2:56 am 
Gabriel HurleyJul 4, 2012 3:17 pm 
Eric WindischJul 4, 2012 4:11 pm 
Christopher B FerrisJul 5, 2012 4:29 am 
Sean DagueJul 5, 2012 6:55 am 
Doug HellmannJul 5, 2012 7:16 am 
Joshua HarlowJul 5, 2012 10:21 am 
Mark McLoughlinJul 18, 2012 2:01 am 
Mark McLoughlinJul 18, 2012 2:13 am 
Mark McLoughlinJul 18, 2012 2:16 am 
Mark McLoughlinJul 18, 2012 2:23 am 
Thierry CarrezJul 18, 2012 4:00 pm 
Doug HellmannJul 23, 2012 8:50 am 
Thierry CarrezJul 23, 2012 8:59 am 
Doug HellmannJul 23, 2012 9:04 am 
Eric WindischAug 2, 2012 1:05 pm 
Christopher B FerrisAug 2, 2012 2:08 pm 
Vishvananda IshayaAug 2, 2012 3:47 pm 
Jay PipesAug 2, 2012 5:18 pm 
Zhongyue LuoAug 2, 2012 5:24 pm 
Eric WindischAug 2, 2012 5:51 pm 
Mark McLoughlinAug 2, 2012 10:26 pm 
Thierry CarrezAug 3, 2012 2:49 am 
Thierry CarrezAug 3, 2012 4:02 am 
Jay PipesAug 3, 2012 9:25 am 
Eric WindischAug 3, 2012 9:34 am 
Subject:[Openstack] best practices for merging common into specific projects
From:Andrew Bogott (abog@wikimedia.org)
Date:Jul 2, 2012 12:16:12 pm
List:net.launchpad.lists.openstack

Having spent some time last week writing code for openstack-common, and having spent yet more time trying to get those changes into Nova, I think it would be useful to define some best practices when crossing the boundary between common and other openstack projects.

Background:

The openstack-common project is subject to a standard code-review process (and, soon, will also have Jenkins testing gates.) Sadly, patches that are merged into openstack-common are essentially orphans. Bringing those changes into actual use requires yet another step, a 'merge from common' patch where the code changes in common are copied into a specific project (e.g. nova.) Merge-from-common patches are generated via an automated process. Specific projects express dependencies on specific common components via a config file, e.g. 'nova/openstack-common.conf'. The actual file copy is performed by 'openstack-common/update.py,' and its behavior is governed by the appropriate openstack-common.conf file.

Questions:

When should changes from common be merged into other projects? What should a 'merge-from-common' patch look like? What code-review standards should core committers observe when reviewing merge-from-common patches?

Proposals:

I. As soon as a patch drops into common, the patch author should submit merge-from-common patches to all affected projects. A. (This should really be done by a bot, but that's not going to happen overnight)

II. In the event that I. is not observed, merge-from-common patches will contain bits from multiple precursor patches. That is not only OK, but encouraged. A. Keeping projects in sync with common is important! B. Asking producers of merge-from-common patches to understand the full diff will discourage the generation of such merges.

III. Merge-from-common patches should be the product of a single unedited run of update.py. A. If a merge-from-common patch breaks pep8 or a test in nova, don't fix the patch; fix the code in common.

IV. Merge-from-common patches are 'presumed justified'. That means: A. Reviewers of merge-from-common patches should consider test failures and pep8 breakages, and obvious functional problems. B. Reviewers of merge-from-common patches should not consider the usefulness, design, etc. of merge-from-common patches. Such concerns need to be handled within the common review process. C. Merges from common should get reviewed early and approved readily in order to avoid project divergence

V. Changes to openstack-common.conf are a special case. A. Patches with openstack-common.conf changes should include the relevant merge-from-common changes. B. Such patches should /not/ include any other merge-from-common changes. C. Such patches should not only include the common merges, but should also include whatever code changes make use of the new merge. D. Such patches require the same justification and scrutiny as any other standard project patch.

Please discuss! If we're able to reach general agreement about this process, I will document the process in the openstack-common HACKING guidelines.

-Andrew

On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:

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.