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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
