On Sat, Oct 29, 2011 at 1:35 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > The policy I aim for (though no doubt I screw it up) is: every patch I > commit should have previously been cc:'d to the appropriate places, in > the form it's applied (eh, modulo whitespace fixes or fixups nearly that > trivial). And some time should pass before committing. (Totally > trivial stuff I figure I can get away with committing immediately, > stuff I don't expect much argument over might sit only 24 hours, > anything big I try to make sure potential reviewers have a few days to > respond.) > >> And with him breaking the patches into smaller pieces, >> I can see why he was reluctant to post a 50 patch series, >> but posted a link to them. > > Another approach is to break up the 50 patches into logical subsets > (especially good is if you can split out any of them as cleanup or > bugfixes that can be justified entirely on their own). He did a reasonable job of breaking them down, but I also suggested to him that he defer some of the unrelated cleanup (e.g. a couple cifs functions moved from one file to a (more logical) other file which increases the patch size but doesn't have anything to do with smb2). The part that hits existing cifs code is not bad, and is the part I am most worried about for careful review in the short term. As we saw with pNFS, I expect multiple changes, cleanup, rework of the smb2 specific functions over time, partly because smb2 (the protocol) is being enhanced - smb 2.2 brings some very interesting new features, and partly due to adding a few linux extensions (once the support for smb2.1 passes all functional tests) and partly because we are going to continue to learn more at every test event. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
