openstack team mailing list archive

[Ed Leafe <ed@xxxxxxxxx>]

On Feb 3, 2011, at 9:33 AM, Ewan Mellor wrote:

> Maybe we should normally do big-picture merges normally, but have an exception procedure for when we'd like them piecemeal.


	I think the main differentiator should be if the partial merge can stand on its own. IOW, with something like the logging change, the first merge would include any code to support the new logging changes, but after that, going through all the files that need to be updated to use this change is mainly exhaustive busy work. Effectively, the single project could be merged as:

a) add changed logging code
b) change a bunch of files to use new logging
c) change a bunch more files to use new logging
d) change a bunch more files to use new logging
... repeat in bite-size chunks
z) final commit of changes.

	This way, at any point, everything will continue to work; the only "problem" is that some code will be using the new logging, and other will continue to use the old logging. 

	The main advantage is that reviewers will avoid having to wade through miles-long diffs. Having to go through diffs that are extremely long increases the chance that the reviewers eyes may miss a typo or some other problem.



-- Ed Leafe