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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
