Date:	Fri, 18 Sep 2015 22:18:27 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Theodore Ts'o <tytso@....edu>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Eric Curtin <ericcurtin17@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

On Fri, Sep 18, 2015 at 10:26:24PM -0400, Theodore Ts'o wrote:
> 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.

All patches have a "cost", and that cost is something that you have to
deal with as a maintainer.  Nothing new here at all, and if you don't
like cleanup patches, great, don't take them.  But never go around
saying that people should NOT send cleanup patches to subsystems you
don't maintain like you did.  That's rude and unhelpful to everyone
involved.

The best way to ensure that you never get whitespace patches, is to
clean your subsystem up.  And frankly, it needs a lot of work, have you
run checkpatch on it in a while?  You could resolve this issue for
yourself with a simple afternoon's worth of work.  Why you don't do so
is a mystery to me.

> Rather, what concerns me is that we aren't pushing people to go
> *beyond* cleanup patches.

On the contrary, I do this ALL THE TIME!  Maybe you don't see it as you
aren't on the staging mailing lists or other places where I do this.
Maybe if you started accepting cleanup patches to your subsystem, you
could start doing this yourself as well.

> 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.

You first have to crawl before you can run.

And write those tutorials please.  The act of writing the "write your
first kernel patch" tutorial showed that it is NOT a trivial thing to
do, and that there are tons of steps involved now that people use web
email clients and email servers that corrupt text emails (i.e.
Exchange), things that when we started out doing kernel development were
not an issue at all.

> 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.

I have never said that at all, and have actively worked for the past 2
years to help provide guidance and work to get people from the "cleanup
patch" to "writing real code."  And it works, look at the Outreachy
program for loads of examples of this (i.e. almost every person who goes
through it gets a job offer.)

I have been saying for years that we have a lack of real projects /
tasks / ideas for people who are skilled, yet have no idea what to do.
I know of well over a hundred people I have email addresses of that have
asked me for these types of things, and have patches in the kernel that
are non-trivial to prove that they have the skill to do real things.

It's a real problem, and one that I don't have an answer for.  We need
these types of tasks, and I don't have them, and every maintainer I ask
about it also doesn't have them.  What we are asking for is people to
somehow come up with tasks on their own, as if they know what needs to
be done.

Remember, when we started, the number of things that needed to be done
was hugely obvious, everywhere we turned needed lots of work.  For
people new to the kernel, this isn't the case anymore.  Linux has taken
over the world because it is so capable and feature rich.  Picking up a
week-end task is almost impossible because of this.  I know, I have no
week-end-length tasks on my TODO list.

So, have any tasks that people can do on a week-end that you know of?

> > 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.

Not at all, I have been working on making people skilled on numerous
projects, and to be frank, it's been working (i.e I have real numbers
and data to back it up and have presented at numerous conferences in
2014 all about it).  But the lack of "what do I do now that I have the
skill" is the major piece we are missing at the moment.

And again, don't knock the basic whitespace patch.  It is non-trivial,
see the tutorials for proof of that.

And please, NEVER chide someone for contributing whitespace patches,
it's a sure way to ensure that this person never contributes again,
something that I hope you agree is toxic to our future.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists