Note: my explanations below are based on how I understand these things, but I'm not the trivial patch monkey nor did I help create these guidelines, so I'm in no way authoritative on the subject.
On 13/07/07, TripleX Chung <[EMAIL PROTECTED]> wrote:
I am working on the chinese translated version of Documentation/SubmittingPatches and get some problem about the "Trivial patches".I can not understand what "Trivial patches" exactly means.The documentation said:
If you are unclear of the meaning of the word "trivial", then take a look here for an explanation: http://www.m-w.com/dictionary/trivial
Trivial patches must qualify for one of the following rules: Spelling fixes in documentation //Understand Spelling fixes which could break grep(1) //Is there any wrong spelling won't break grep(1)?
Hmm, trying to think of examples and all I can think of is stuff like "its" & "it's" - quite different meaning, very similar spelling. Someone else can probably think of a better example...
Warning fixes (cluttering with useless warnings is bad) //Understand Compilation fixes (only if they are actually correct) //Understand Runtime fixes (only if they actually fix things) //What kind of runtime fixes? Could anyone give some examples?
A simple and obviously correct fix for a memory leak. A simple and obviously correct fix for a NULL pointer dereference. A simple and obviously correct fix for a off by one error in a loop. A simple and obviously correct fix for a buffer overrun. Stuff like that.
Removing use of deprecated functions/macros (eg. check_region) //Understand Contact detail and documentation fixes //Means Contact detail fixes and documentation fixes, right?
That's how I have always read it.
Are all the documentation fixes "trivial"?
No. Something like fixing a misspelled word, correcting capitalization, adding a description of something that's currently missing a description (assuming the description if correct), removing trailing whitespace, and similar things would be trivial. When you start changing the meaning of documentation then it needs to be verified that what you write is actually correct, that is then no longer a trivial change.
Non-portable code replaced by portable code (even in arch-specific, since people copy, as long as it's trivial) //Do not understand the words in the brackets.
It means that it's OK to replace non-portable code by portable code even in architecture specific parts of the kernel, since people tend to copy code from one architecture to another, so having even arch-specific code portable is good since that means it will probably still work when someone copies it to a different architecture. The changes you make to the code to make it portable still have to be trivial in nature though.
Any fix by the author/maintainer of the file (ie. patch monkey in re-transmission mode) //It means if I am the author of a file, when I modify the file, the patch is trivial, right?
Right. Maintainers are trusted to know what they are doing with the code they maintain (and authors as well), so when the author or maintainer of a piece of code submits a patch to the trivial patch monkey, then it's accepted as OK.
Please give me some advice. Thanks in advance.
I hope the above make things a little clearer. :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
