From: Joe Perches <joe@perches.com>
To: Kalle Valo <kvalo@codeaurora.org>, linux-wireless@vger.kernel.org
Cc: kbuild test robot <lkp@intel.com>,
kernel-janitors <kernel-janitors@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: wireless-drivers: random cleanup patches piling up
Date: Thu, 21 Jan 2016 16:52:45 -0800 [thread overview]
Message-ID: <1453423965.3856.22.camel@perches.com> (raw)
In-Reply-To: <87wpr3x9ln.fsf@kamboji.qca.qualcomm.com>
On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote:
> Hi,
>
> I have quite a lot of random cleanup patches from new developers waiting
> in my queue:
>
> https://patchwork.kernel.org/project/linux-wireless/list/?state=10&delegate=25621&order=date
>
> (Not all of them are cleanup patches, there are also few patches
> deferred due to other reasons, but you get the idea.)
>
> These cleanup patches usually take quite a lot of my time and I'm
> starting to doubt the benefit, compared to the time needed to dig
> through them and figuring out what to apply. And this is of course time
> away from other patches, so it's slowing down "real" development.
>
> I really don't know what to do. Part of me is saying that I just should
> drop them unless it's reviewed by a more experienced developer but on
> the other hand this is a good way get new developers onboard.
>
> What others think? Are these kind of patches useful?
Some yes, mostly not really.
While whitespace style patches have some small value,
very few of the new contributors that use tools like
"scripts/checkpatch.pl -f" on various kernel files
actually continue on to submit actual defect fixing
or optimization or code clarity patches.
Whitespace patches, where git diff -w does not show
any difference and objdiff on the objects for a few
randconfigs are identical, maybe could be sifted
into a separate category from other patches.
Maybe the kbuild test robot could help identify the
whitespace style
patches that can be easily applied.
Maybe the kernel-janitors list should be used and
also maybe some maintainers that want these style
patches could opt-in to getting these applied after
some milestone like an -rc1.
Fengguang?
next parent reply other threads:[~2016-01-22 0:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wpr3x9ln.fsf@kamboji.qca.qualcomm.com>
2016-01-22 0:52 ` Joe Perches [this message]
2016-01-22 7:30 ` wireless-drivers: random cleanup patches piling up Dan Carpenter
2016-01-22 12:21 ` Kalle Valo
2016-01-22 15:12 ` John W. Linville
2016-01-22 15:54 ` Kalle Valo
2016-01-26 5:28 ` Sudip Mukherjee
2016-01-29 8:08 ` Kalle Valo
2016-02-01 4:41 ` Sudip Mukherjee
2016-02-01 8:21 ` Kalle Valo
2016-03-16 0:57 ` Julian Calaby
2016-03-16 9:22 ` Kalle Valo
2016-03-16 9:42 ` Julian Calaby
2016-03-18 1:06 ` Julian Calaby
2016-01-22 18:05 ` Joe Perches
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=1453423965.3856.22.camel@perches.com \
--to=joe@perches.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lkp@intel.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