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.
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... John Postlethwait Nebula, Inc. 206-999-4492 On Monday, July 2, 2012 at 2:41 PM, Joshua Harlow wrote: > Re: [Openstack] best practices for merging common into specific projects What > about using openstack-common as a library instead of a preprocessor > ‘inclusion’ system/copy code around system....?? > > Maybe its time for that to happen? > > 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. > > On 7/2/12 12:16 PM, "Andrew Bogott" <abog...@wikimedia.org> wrote: > > > 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 (mailto: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