++ 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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
