lkml.org 
[lkml]   [2015]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: First kernel patch (optimization)
    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


    \
     
     \ /
      Last update: 2015-09-19 14:41    [W:4.155 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site