Hi Sandro,
It's not mentioned in the process documentation (but maybe we should
add this), is that it's up to individual maintainers about whether or
not whitespace cleanups are accepted outside of the staging tree.
That's because whitespace cleanups are a great "training wheel" for
newbies who are learning the ropes, but they do have some costs. For
example, for actively developed portions of the kernel whitespace
cleans can often break other pending changes. Also, trivial cleanups
(e.g., spelling and whitespace cleanups) makes it more likely that
future bug fixes in that portion of the kernel will fail to be
automatically backported to the stable kernel, thus requiring a manual
backport effort.
As a result, some maintainers will reject trivial cleanups unless they
are part of a patch series that is making some kind of substantive
improvement to the kernel (beyond trivial cleanups).
There are some good aspects of fixing whitespace issues, of course,
which is why they are encouraged in the staging tree, but there is not
consensus amongst maintainers about whether it is a net benefit to do
clean up patches just for the sake of doing cleanup patches.
(And of course, sometimes the checkpatch rules change over time --- at
one point, checkpatch would warn if *any* line was longer than 80
characters, and so there were tons and tons of trivial cleanups to
"fix" this, including breaking up strings. When enough people
complained that this actually made it harder to find kernel messages
that got split, checkpatch changed to complain when strings were split
across lines, and more trivial patches got sent out undoing previous
trivial patches. And this caused all of the same downsides of
breaking automated stable backports, *twice*. As such, newbies are
strongly encouraged to restrict their checkpatch cleanups to the
staging tree, since when such cleanup patches are considered welcome
very much depends on the kernel subsystem and the maintainers
involved.)
Cheers,
- Ted
