Open Stack

On 07/03/2012 02:00 PM, Dan Prince wrote:
>> 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.
>
> I went on a bit of a rant about this on IRC yesterday. While I agree a patch series is appropriate for many new features and bug fixes I don't think it should be required for keeping openstack-common in sync. Especially since we don't merge tests from openstack-common which would help verify that the person doing the merges doesn't mess up the order of the patchset. If we were to include the tests from openstack-common in each project this could change my mind.
>
> If someone wants to split openstack-common changes into patchsets that might be Okay in small numbers. If you are merging say 5-10 changes from openstack common into all the various openstack projects that could translate into a rather large number of reviews (25+) for things that have been already reviewed once.  For me using patchsets to keep openstack-common in sync just causes thrashing of Jenkins, SmokeStack, etc. for things that have already been gated. Seems like an awful waste of review/CI time. In my opinion patchsets are the way to go with getting things into openstack-common... but not when syncing to projects.
>
> Hopefully this situation is short lived however and we start using a proper library sooner rather than later.

+1. I think the bisectability isn't a clear win without the unit tests 
coming over, and the rest is just more reviews (which are already in 
scarce supply), and more jenkins time which just slows down everything else.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com