|Andrew Bogott||Jul 2, 2012 12:16 pm|
|Russell Bryant||Jul 2, 2012 12:26 pm|
|Joshua Harlow||Jul 2, 2012 2:41 pm|
|Joshua Harlow||Jul 2, 2012 2:54 pm|
|Gabriel Hurley||Jul 2, 2012 3:18 pm|
|John Postlethwait||Jul 2, 2012 4:42 pm|
|Christopher B Ferris||Jul 2, 2012 5:41 pm|
|Thierry Carrez||Jul 3, 2012 2:31 am|
|Thierry Carrez||Jul 3, 2012 2:34 am|
|Doug Hellmann||Jul 3, 2012 5:37 am|
|James E. Blair||Jul 3, 2012 6:55 am|
|Joshua Harlow||Jul 3, 2012 10:46 am|
|Dan Prince||Jul 3, 2012 10:59 am|
|Gabriel Hurley||Jul 3, 2012 11:59 am|
|Andrew Bogott||Jul 3, 2012 12:47 pm|
|Joshua Harlow||Jul 3, 2012 2:09 pm|
|James E. Blair||Jul 3, 2012 2:54 pm|
|Eric Windisch||Jul 3, 2012 3:47 pm|
|Andrew Bogott||Jul 3, 2012 3:54 pm|
|Gabriel Hurley||Jul 3, 2012 4:53 pm|
|Timothy Daly||Jul 3, 2012 5:27 pm|
|Monty Taylor||Jul 3, 2012 6:17 pm|
|Thierry Carrez||Jul 4, 2012 2:56 am|
|Gabriel Hurley||Jul 4, 2012 3:17 pm|
|Eric Windisch||Jul 4, 2012 4:11 pm|
|Christopher B Ferris||Jul 5, 2012 4:29 am|
|Sean Dague||Jul 5, 2012 6:55 am|
|Doug Hellmann||Jul 5, 2012 7:16 am|
|Joshua Harlow||Jul 5, 2012 10:21 am|
|Mark McLoughlin||Jul 18, 2012 2:01 am|
|Mark McLoughlin||Jul 18, 2012 2:13 am|
|Mark McLoughlin||Jul 18, 2012 2:16 am|
|Mark McLoughlin||Jul 18, 2012 2:23 am|
|Thierry Carrez||Jul 18, 2012 4:00 pm|
|Doug Hellmann||Jul 23, 2012 8:50 am|
|Thierry Carrez||Jul 23, 2012 8:59 am|
|Doug Hellmann||Jul 23, 2012 9:04 am|
|Eric Windisch||Aug 2, 2012 1:05 pm|
|Christopher B Ferris||Aug 2, 2012 2:08 pm|
|Vishvananda Ishaya||Aug 2, 2012 3:47 pm|
|Jay Pipes||Aug 2, 2012 5:18 pm|
|Zhongyue Luo||Aug 2, 2012 5:24 pm|
|Eric Windisch||Aug 2, 2012 5:51 pm|
|Mark McLoughlin||Aug 2, 2012 10:26 pm|
|Thierry Carrez||Aug 3, 2012 2:49 am|
|Thierry Carrez||Aug 3, 2012 4:02 am|
|Jay Pipes||Aug 3, 2012 9:25 am|
|Eric Windisch||Aug 3, 2012 9:34 am|
|Subject:||Re: [Openstack] best practices for merging common into specific projects|
|From:||Mark McLoughlin (mar...@redhat.com)|
|Date:||Jul 18, 2012 2:01:14 am|
(Sorry, was away for a couple of weeks)
On Mon, 2012-07-02 at 15:26 -0400, Russell Bryant wrote:
On 07/02/2012 03:16 PM, Andrew Bogott wrote:
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.
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?
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)
All of the APIs in openstack-common right now are considered to be in incubation, meaning that breaking changes could be made. I don't think automated merges are good for anything in incubation.
Automation would be suitable for stable APIs. Once an API is no longer in incubation, we should be looking at how to make releases and treat it as a proper library. The copy/paste madness should be limited to APIs still in incubation.
There are multiple APIs close or at the point where I think we should be able to commit to them. I'll leave the specifics for a separate discussion, but I think moving on this front is key to reducing the pain we are seeing with code copying.
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.
I don't see this as much different as any other patches to nova (or whatever project is using common). It should be a proper patch series. If the person pulling it in doesn't understand the merge well enough to produce the patch series with proper commit messages, then they are the wrong person to be doing the merge in the first place.
It sounds like there was some confusion as to what you meant here. All people need to do to understand is look at how you have been syncing stuff into Nova e.g.
or one of my syncs: