Open Stack

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" <abogott at 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 at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >  
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net (mailto:openstack at lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120702/30705d2b/attachment.html>