89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
---
|
|
created_at: '2014-09-24T17:17:45.000Z'
|
|
title: The biggest thing with small patches (2004)
|
|
url: https://lkml.org/lkml/2004/12/20/255
|
|
author: ohmygeek
|
|
points: 392
|
|
story_text: ''
|
|
comment_text:
|
|
num_comments: 41
|
|
story_id:
|
|
story_title:
|
|
story_url:
|
|
parent_id:
|
|
created_at_i: 1411579065
|
|
_tags:
|
|
- story
|
|
- author_ohmygeek
|
|
- story_8362707
|
|
objectID: '8362707'
|
|
year: 2004
|
|
|
|
---
|
|
![/](/images/icornerl.gif)DateMon, 20 Dec 2004 16:56:13 -0800
|
|
(PST)FromLinus Torvalds \<\>SubjectRe: \[PATCH\] kill access\_ok() call
|
|
from copy\_siginfo\_to\_user() that we might as well
|
|
avoid.
|
|
|
|
[ Linux-kernel added back into the cc, because I actually think this is
|
|
important. ]
|
|
|
|
On Tue, 21 Dec 2004, Jesper Juhl wrote:
|
|
>
|
|
> Should I just stop attemting to make these trivial cleanups/fixes/whatever
|
|
> patches? are they more noice than gain? am I being a pain to more skilled
|
|
> people on lkml or can you all live with my, sometimes quite ignorant,
|
|
> patches?
|
|
> I do try to learn from the feedback I get, and I like to think that my
|
|
> patches are gradually getting a bit better, but if I'm more of a bother
|
|
> than a help I might as well stop.
|
|
|
|
To me, the biggest thing with small patches is not necessarily the patch
|
|
itself. I think that much more important than the patch is the fact that
|
|
people get used to the notion that they can change the kernel - not just
|
|
on an intellectual level ("I understand that the GPL means that I have the
|
|
right to change my kernel"), but on a more practical level ("Hey, I did
|
|
that small change").
|
|
|
|
And whether it ends up being the right thing or not, that's how everybody
|
|
starts out. It's simply not possible to "get into" the kernel without
|
|
starting out small, and making mistakes. So I very much encourage it, even
|
|
if I often don't have the time to actually worry about small patches, and
|
|
I try to get suckers^H^H^H^H^H^H^Hother developers like Rusty to try to
|
|
acts as quality control and a "gathering place".
|
|
|
|
Btw, this is why even "trivial patches" really do take time - they often
|
|
have trivial mistakes in them, and it's not just because there are more
|
|
inexperienced people doing them - most of _my_ mistakes tend to be at the
|
|
truly idiotic level, just because it "looked obvious", and then there's
|
|
something that I miss.
|
|
|
|
So at one level I absolutely _hate_ trivial patches: they take time and
|
|
effort to merge, and individually the patch itself is often not really
|
|
obviously "worth it". But at the same time, I think the trivial patches
|
|
are among the most important ones - exactly because they are the "entry"
|
|
patches for every new developer.
|
|
|
|
I just try really hard to find somebody else to worry about them ;)
|
|
|
|
(It's not a thankful job, btw, exactly because it _looks_ so trivial. It's
|
|
easy to point to 99 patches that are absolutely obvious, and complain
|
|
about the fact that they haven't been merged. But they take time to merge
|
|
exactly because of that one patch that _did_ look obvious, but wasn't.
|
|
And actually, it's usually not 99:1, it's usually more like 10:1 or
|
|
something).
|
|
|
|
So please don't stop. Yes, those trivial patches _are_ a bother. Damn,
|
|
they are _horrible_. But at the same time, the devil is in the detail, and
|
|
they are needed in the long run. Both the patches themselves, and the
|
|
people that grew up on them.
|
|
|
|
Linus
|
|
-
|
|
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
|
|
the body of a message to majordomo@vger.kernel.org
|
|
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
|
Please read the FAQ at http://www.tux.org/lkml/
|
|
|
|
![\\](/images/icornerr.gif)
|