Re: Ask for help, about the trivial patches.

["Jesper Juhl" <jesper.juhl@gmail.com>]

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 <triplex@zh-kernel.org> 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 <jesper.juhl@gmail.com>
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 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/