On Thu, Sep 25, 2014 at 08:22:15AM -0500, Romer, Benjamin M wrote: > On Thu, 2014-09-25 at 00:02 +0200, Greg KH wrote: > > On Wed, Sep 24, 2014 at 07:12:03PM +0300, Dan Carpenter wrote: > > > Gar. I hate to make you redo a lot of work but these need to be broken > > > up into "one thing per patch". That rules is kind of vague so we > > > normally tell people to fix one type of checkpatch.pl warning at a time > > > as a simple way of explaining it. > > > > > > But definitely "fixing every checkpatch.pl warning in a file" is not > > > one thing unless there are like 2 lines of change only. > > > > I agree, please fix this up into "one logical change per patch". > > > > thanks, > > > > greg k-h > > That's no problem, the same amount of work needs to get done regardless > of how it's split up. :) > > When you say type of warning, do you mean individual warnings, or can I > group them into sets, i.e. fixing spacing and doubled blank lines > together as a single whitespace formatting patch? Probably that's fine, but normally we suggest: patch 1: clean up long lines patch 2: delete extra blank lines patch 3: comments or whatever... > > When fixing the camel-case warnings do I need to do a separate patch for > each function or variable or struct, or can I group all of the > camel-case fixes for a single file together? These things are kind of vague. The "clean everything in a file" approach is definitely banned. What really helps me is if you list the exact variables that were changed in the changelog like this: Cleanup CamelCase names: FooBar => foo_bar OneTwo => one_two I use a script to sed these renames out so I can just cut and paste the renames and verify that nothing else changed. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
