From: "Theodore Ts'o" <tytso@mit.edu>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
Eric Curtin <ericcurtin17@gmail.com>,
Austin S Hemmelgarn <ahferroin7@gmail.com>,
Steve Calfee <stevecalfee@gmail.com>,
Valentina Manea <valentina.manea.m@gmail.com>,
Shuah Khan <shuah.kh@samsung.com>,
USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: First kernel patch (optimization)
Date: Fri, 18 Sep 2015 22:26:24 -0400 [thread overview]
Message-ID: <20150919022624.GB2921@thunk.org> (raw)
In-Reply-To: <20150918074248.GA10792@kroah.com>
On Fri, Sep 18, 2015 at 12:42:48AM -0700, Greg KH wrote:
> So don't take cleanup patches for your code, that's fine, and I totally
> understand why _you_ don't want to do that. But to blow off the effort
> as being somehow trivial and not worthy of us, that's totally missing
> the point, and making things harder on yourself in the end.
It's not that I think cleanup patches are "trivial and not worthy of
us", although I'll note that cleanup patches can end up causing real
bug fixes (including possibly fixes that address security problems) to
not apply to stable kernels, which means someone needs to deal with
failed patches --- or what is much more likely, the failed patch gets
bounced back to the overworked maintainer who then drops the patch
because he or she doesn't have the bandwidth to manually backport the
patch to N different stable trees, and then we all suffer. So cleanup
patches *do* have a cost.
Rather, what concerns me is that we aren't pushing people to go
*beyond* cleanup patches. We have lots of tutorials about how to
create perfectly formed patches; but we don't seem to have patches
about how to do proper benchmarking. Or how to check system call and
ioctl interfaces to make sure the code is doing appropriate input
checking. So I don't want to pre-reject these people; but to rather
push them and to help them to try their hand at more substantive work.
What surprises me is the apparent assumption that people need a huge
amount of hand-holding on how to properly form a patch, but that
people will be able to figure out how to do proper benchmarking, or
design proper abstractions, etc., as skills that will magically appear
full-formed into the new kernel programmer's mind without any help or
work on our part.
> So don't be a jerk, and spout off as to how we only need "skilled"
> people contributing. Of course we need that, but the way we get those
> people is to help them become skilled, not requiring them to show up
> with those skills automatically.
I think where we disagree is in how to make them become skilled. I
don't think just focusing on contents of SubmittingPatches is
sufficient, and there seems to be a "Step 2: And then a miracle
occurs" between the SubmittingPatches step and the "skilled
contributor" end goal.
Cheers,
- Ted
next prev parent reply other threads:[~2015-09-19 2:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 19:53 First kernel patch (optimization) Eric Curtin
2015-09-15 20:11 ` Felipe Balbi
2015-09-16 0:09 ` Steve Calfee
2015-09-16 11:45 ` Austin S Hemmelgarn
2015-09-16 12:56 ` David Laight
2015-09-17 1:49 ` Jaime Arrocha
2015-09-17 8:45 ` David Laight
2015-09-16 13:24 ` Greg KH
2015-09-16 16:03 ` Eric Curtin
2015-09-16 16:40 ` Theodore Ts'o
2015-09-16 17:24 ` Raymond Jennings
2015-09-16 17:26 ` Josh Boyer
2015-09-18 3:12 ` Theodore Ts'o
2015-09-18 7:42 ` Greg KH
2015-09-18 9:31 ` Raymond Jennings
2015-09-18 19:08 ` Austin S Hemmelgarn
2015-09-19 2:26 ` Theodore Ts'o [this message]
2015-09-19 4:22 ` Sudip Mukherjee
2015-09-19 5:18 ` Greg KH
2015-09-19 12:20 ` Theodore Ts'o
2015-09-19 12:52 ` Alexander Holler
2015-09-19 14:14 ` Alexander Holler
2015-09-19 14:22 ` Theodore Ts'o
2015-09-19 17:47 ` Alexander Holler
2015-09-20 2:21 ` Theodore Ts'o
2015-09-20 10:41 ` Alexander Holler
2015-09-21 15:47 ` Austin S Hemmelgarn
2015-09-21 17:20 ` Alexander Holler
2015-09-21 18:41 ` Alexander Holler
2015-09-23 8:59 ` Alexander Holler
2015-09-28 6:54 ` Thiago Farina
2015-09-28 14:20 ` Greg KH
2015-09-16 20:02 ` Greg KH
2015-09-16 20:21 ` Eric Curtin
2015-09-16 22:38 ` Greg KH
2015-09-22 17:38 ` Linus Torvalds
2015-09-22 18:18 ` Eric Curtin
2015-09-25 22:06 ` Dmitry Torokhov
2015-09-26 13:28 ` Eric Curtin
2015-09-29 13:51 ` Austin S Hemmelgarn
2015-09-29 14:47 ` Eric Curtin
-- strict thread matches above, loose matches on Subject: below --
2015-09-15 19:52 Eric Curtin
2015-09-15 21:57 ` Alexander Duyck
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=20150919022624.GB2921@thunk.org \
--to=tytso@mit.edu \
--cc=ahferroin7@gmail.com \
--cc=ericcurtin17@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah.kh@samsung.com \
--cc=stevecalfee@gmail.com \
--cc=valentina.manea.m@gmail.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