From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Sandro Volery <sandro@volery.com>
Cc: Joe Perches <joe@perches.com>,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fixed most indent issues in tty_io.c
Date: Sun, 8 Sep 2019 16:59:31 -0400 [thread overview]
Message-ID: <20190908205931.GG23683@mit.edu> (raw)
In-Reply-To: <C511485C-6194-4B31-BA98-C4C9000062AD@volery.com>
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
next prev parent reply other threads:[~2019-09-08 20:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-07 9:09 [PATCH] Fixed most indent issues in tty_io.c volery
2019-09-07 17:07 ` Greg KH
2019-09-07 20:04 ` Joe Perches
2019-09-07 20:30 ` Sandro Volery
2019-09-08 20:59 ` Theodore Y. Ts'o [this message]
2019-09-09 8:17 ` Sandro Volery
[not found] <20190907172944.GB18166@kroah.com>
2019-09-07 17:35 ` Sandro Volery
2019-09-07 17:42 ` Greg KH
2019-09-07 17:49 ` Sandro Volery
2019-09-07 18:02 ` Greg KH
2019-09-07 18:05 ` Sandro Volery LKML
2019-09-07 19:27 ` Joe Perches
2019-09-07 19:51 ` Sandro Volery
2019-09-07 20:01 ` Joe Perches
-- strict thread matches above, loose matches on Subject: below --
2019-09-08 23:32 Sandro Volery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190908205931.GG23683@mit.edu \
--to=tytso@mit.edu \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sandro@volery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox