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....@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula....@lists.launchpad.net] On Behalf Of
> Andrew Bogott
> Sent: Monday, July 02, 2012 12:17 PM
> To: openstack@lists.launchpad.net
> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
