On Fri, Oct 26, 2012 at 5:45 PM, Greg Freemyer [off-list ref]wrote:

On Thu, Oct 25, 2012 at 4:27 PM, Eugene Voronkov
[off-list ref] wrote:

quoted

I watched Kroah-Hartman's video[1] on submitting patches where he walks
through the process of fixing coding style.  I feel like this would be a
good way for me to jump into the process but I need more information.  At
what point do code style patches stop being more trouble then they're

worth

quoted

to the maintainers?  For example, running checkpatch.pl against all

files is

quoted

showing around 3 non-trivial style violations per file.  Would a patch
fixing 12 violations across 4 files be worth submitting?

1. http://www.youtube.com/watch?v=LLBrBBImJt4

Before spending time on this, read the email on the ext4 list from a
couple weeks ago.

http://marc.info/?l=linux-ext4&m=135048406513682&w=2

Basically pure checkpatch.pl generated patches are discouraged by a
lot of maintainers.

They break existing out of tree patches that people may be working on.

The solution is to use checkpatch.pl when you are already working in a
relevant code area.

Then it becomes:

0/2  This is a patch series to fix such and such bug
1/2  checkpatch.pl patch to clean up the formatting of the files I'm
working on.
2/2 patch to fix the bug

I see that sequence all the time and the checkpatch cleanup is always
taken.

But a sequence of purely checkpatch cleanups will likely be rejected.

fyi: Robert Day just asked for help cleaning up the Doc Book stuff.

Doc Book pull comments out of the .c files and creates documentation.
To clean it up, patches to the source files will be required.  These
are more likely to be accepted.

So you could to a doc book series like:

0/2 a patch series to correct the documentation for xyz subsystem
1/2 checkpatch cleanup of the 2 files with doc updates
2/2 doc updates

That pairing may actually get accepted.  (I can't say I remember it
being tried.)

Greg

Yea, seems like they would cause more problems than they solve.

Thanks for the heads up.  I've been looking at those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121026/1ec35848/attachment.html