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