openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

On a more fundamental level, did I miss some tremendous reason why we have this "merge from common" pattern instead of making OpenStack Common a standard python dependency just like anything else? Especially with the work Monty has recently done on versioning and packaging the client libs from Jenkins, I can't see a reason to keep following this "update common and merge to everything else" pattern at all...

    - Gabriel

> -----Original Message-----
> From: openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-
> bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Andrew Bogott
> Sent: Monday, July 02, 2012 12:17 PM
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: [Openstack] best practices for merging common into specific
> projects
> 
>      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.
> >
> >
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp