openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

++ on all below points :) There are few bugs or blueprints that
actually require a huge patch. Most things can be done in small
chunks, making sure each chunk doesn't break tests...

-jay

On Thu, Feb 3, 2011 at 10:03 AM, Ed Leafe <ed@xxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>