Re: First kernel patch (optimization)

[Theodore Ts'o]

On Fri, Sep 18, 2015 at 10:18:27PM -0700, Greg KH wrote:
> 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.

Not less than 24 hours ago, I received a "my second kernel patch[1]"
contribution which doesn't even compile (and no, it wasn't from Nick
Krause).  It was a hundred+ lines of diffs of the form:

-	printf("Hello, world\n");
+	printf("Hello,
+			world\n");

and

-	foo(a, b, c, d); /* nowhere near 80 characters */
+	foo(a, b,        /* Oooookay; so what was the point? */
+	    c, d);

(Reference ommitted because I don't want to embarass the contributor;
people who really want to find it should have no trouble doing so.)

I didn't childe the contributor for submitting a whitespace patch.  I
childed him on creating a patch which didn't build after you applied
it.  And I pointed him at kvm-xfstests and gce-xfstests, for which I
have spent a lot of time making them as turn key and as easy to use as
possible, specifically because I *am* trying to make life easier for
newcomers.  (Although if we have people who aren't clear on the
concept of valid C code, I'm not sure how much any tutorials or making
test suites more accessible is really going to help.  :-)

I am sure that it is indeed very hard for a certain class of people to
create a basic whitespace patch.  What I haven't seen the data for is
that which addresses the question: for the people for which creating a
whitespace patch is difficult, what percentage of them have the
capability to eventually develop the advanced skills we need for
kernel development?  And how much effort do we need to invest for them
to accomplish this, and how does the amount of investment required to
get them to that stage relate to amount of return these people will
contribute to the community --- that is, is this a charitable donation
where we are asking maintainers to invest in something that will
ultimately not benefit them, or is this a wise long-term investment?

People may still be willing to devote energy if it achieves some other
desirable long-term goal (i.e., increasing the representation of
under-represented groups), even if it doesn't help their subsystem
directly.  But it's useful to know how to pitch the "ask" in terms of
what their expectations should be.


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

How about maintaining a list of people who are in this state?  It
could be as simple as a list of git commit ID's --- their e-mail
addresses will be in the git commit.  Republish it once a month, with
some kind of auto-expiry mechanism unless (a) the author of said git
commit requests that it be removed, or (b) after some time period
unless the author is continuing to submit at least some non-trivial
patch.

At least that way maintainers who are looking for some minions will at
least have a starting point.

As far as creating tasks for people who _are_ skilled, the question is
how picky are these people, and how much time does it take to delegate
work to them?  If it takes 8 hours of effort to delegate 16 hours (a
weekend's worth) of effort, with a 50% probability that the person
won't flaky out, and another 4 hours of work afterwards cleaning up
and debugging the patch.  It has negative overall value to the
maintainer.

Or if the work isn't directly kernel programming, but instead work in
support of kernel programming (i.e., improving documentation, fixing
up regression tests, auditing interfaces looking for security holes),
is this work that "graduates" from the "my first patch" programs
willing to do?

There are almost certainly "bottle-washing" duty style tasks
available, but the question is are they tasks that people will want to
do?  And how much work is a "week-end task" really?  If it takes two
hours to delegate a task the maintainer can do in an hour, but it
takes the newcomer a weekend, then it only makes sense for the
maintainer to do this if (a) they are doing it as a cherity, or (b)
there is a sufficiently high probability the newcomer to stick around.

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

I wonder if we're looking at this problem in the wrong way.  If Linux
is so feature rich, why are we stressing out about our "recruitment
problem"?  Presumably, because there are lots of companies who are
complaining that they can't find enough Linux kernel programmers.
What do many of these companies need the Linux kernel programmers to
do?  I'm going to go out on a limb and say, "hardware enablement".
(That is, the companies are not looking for new subsystem maintainers,
they are looking for device driver cannon fodder.)

So maybe the answer is that we need to figure out some kind of
internship program so people can work for more than just a weekend,
and create a device driver for said company.  And maybe our payment in
kind is that companies who ship product kernels (not just for
development boards, but real SDK's for real commercial products) get
priority --- and the driver has to be developed in an upstream first
basis, or the intern doesn't get a community mentor.

Yes, it will still be a negative ROI for the community mentor, unless
you count the hope that maybe we won't be still be shipping brand-new
products using 3.10 kernel in another year's time.  :-)

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