On 09/18/15 00:42, Greg KH wrote:It's also worth pointing out that if we don't have people submitting code cleanups and typo fixes and stuff like that, then either we end up over time with unmaintainable gibberish, or the people who do know systems programming spending most of their time trying to deal with cleaning up the code (and this is coming from someone who works for a company who's software department used to be almost 50 people and is now 5, and we have exactly this problem (that and for some reason no-one wants to do any kind of code-review, but that's a separate issue)). So in a way, they are contributing something useful, just not something that directly impacts users in any immediate time-frame.
On Thu, Sep 17, 2015 at 11:12:51PM -0400, Theodore Ts'o wrote:+1 for this.
On Wed, Sep 16, 2015 at 01:26:51PM -0400, Josh Boyer wrote:Ted, you are full of crap.
That isn't true. It helps the submitter understand the workflow andThe problem is that workflow isn't the hard part. It's the part that
expectations. What you meant to say is that it doesn't help you.
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.
Where do you think that "new developers" come from? Do they show up in
our inbox, with full knowledge of kernel internals and OS theory yet
they somehow just can't grasp how to submit a patch correctly? Yes,
they sometimes rarely do. But for the majority of people who got into
Linux, that is not the case at all.
People need to start with something simple, and easy, to get over the
hurdles of:
- generating a patch
- sending an email
- fixing the email client as it just corrupted the patch
- fix the subject line as it was incorrect
- fix the changelog as it was missing
- fix the email client again as it corrupted the patch in a
different way
- giving up on using a web email client as it just will not work
- figuring out who to send the patch to
- fixing the email client as the mailing list bounced the email
Those are non-trivial tasks. And by starting with "remove this space"
you take the worry away from the specific content of the patch, and let
them worry about the "hard" part first.
For example, I for one cannot tell you how many times gmail snuck html
sections into my outgoing emails before I finally caught it red handed
and switched to using a local native client.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature