On Wed, Sep 16, 2015 at 01:26:51PM -0400, Josh Boyer wrote: > > That isn't true. It helps the submitter understand the workflow and > expectations. What you meant to say is that it doesn't help you. The problem is that workflow isn't the hard part. It's the part that can be taught most easily, sure. But people seem to get really hung up on it, and I fear that we have people who never progress beyond sending trivial patches and spelling fixes and white space fixes and micro-optimizations. If the "you too can be a kernel developer" classes and web sites and tutorials also taught people how to take performance measurements, and something about the scientific measurement, that would be something. Or if it taught people how to create tests and to run regression testing. Or if it taught people how to try to do fuzz testing, and then once they find a sequence which causes crash, how to narrow down the failure to a specific part of the kernel, and how to fix and confirm that the kernel no longer crashes with the fix --- that would be useful. If they can understand kernel code; if they can understand the scientific measurement; if they can understand how to do performance measurements --- being able to properly format patches is something which most kernel developers can very easily guide a new contributor to do correctly. Or in the worst case, it doesn't take much time for me to fix a whitespace problem and just tell the contributor --- by the way, I fixed up this minor issue; could you please make sure you do this in the future? But if a test hasn't been tested, or if the contributor things it's a micro-optimization, but it actually takes more CPU time and/or more stack space and/or bloats the kernel --- that's much more work for the kernel maintainer to have to deal with when reviewing a patch. So I have a very strong disagreement with the belief that teaching people the workflow is the more important thing. In my mind, that's like first focusing on the proper how to properly fill out a golf score card, and the ettiquette and traditions around handicaps, etc --- before making sure the prospective player is good at putting and driving. Personally, I'm terrible at putting and driving, so spending a lot of time learning how to fill out a golf score card would be a waste of my time. A good kernel programmer has to understand systems thinking; how to figure out abstractions and when it's a good thing to add a new layer of abstraction and when it's better to rework an exsting abstraction layer. If we have someone who knows the workflow, but which doesn't understand systems thinking, or how to do testing, then what? Great, we've just created another Nick Krause. Do you think encouraging a Nick Krause helps anyone? If people really are hung up on learning the workflow, I don't mind if they want to learn that part and send some silly micro-optimization or spelling fix or whitespace fix. But it's really, really important that they move beyond that. And if they aren't capable of moving beyond that, trying to inflate are recruitment numbers by encouraging someone who can only do trivial fixes means that we may be get what we can easily measure --- but it may not be what we really need as a community. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
