Ask for help, about the trivial patches.

Ask for help, about the trivial patches.

[TripleX Chung]

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:

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

 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?

 Removing use of deprecated functions/macros (eg. check_region)
 //Understand

 Contact detail and documentation fixes
 //Means Contact detail fixes and documentation fixes, right?
   Are all the documentation fixes "trivial"?

 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.

 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?

Please give me some advice. Thanks in advance.

Re: Ask for help, about the trivial patches.

[Jesper Juhl]

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

Re: Ask for help, about the trivial patches.

[TripleX Chung]

Jesper Juhl wrote:
> 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
>
Thanks for your help. 
But I still have problems.
Trivial means "of little worth or importance". But some of the examples
in the rules are important, like "runtime fixes". Spell fixes must be
unimportant, but most of the runtime fixes like memory leaks or NULL
pointers must be important. I was still a little confused with them.

-TripleX

Re: Ask for help, about the trivial patches.

[jimmy bahuleyan]

TripleX Chung wrote:
> Jesper Juhl wrote:
>> 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
>>
> Thanks for your help. 
> But I still have problems.
> Trivial means "of little worth or importance". But some of the examples
> in the rules are important, like "runtime fixes". Spell fixes must be
> unimportant, but most of the runtime fixes like memory leaks or NULL
> pointers must be important. I was still a little confused with them.
> 

Literally, yes. But look at it from a s/w engineering point of view.

A NULL pointer deref is important, but it is also a *very local* and
very obvious fix (one that doesn't need extensive testing, one that
doesn't have effects spread out over many modules that requires great
amount of thought).

So such things are trivial bug-fixes.

-jb
-- 
Tact is the art of making a point without making an enemy.

Re: Ask for help, about the trivial patches.

[Stefan Richter]

jimmy bahuleyan wrote:
> TripleX Chung wrote:
>> But I still have problems.
>> Trivial means "of little worth or importance". But some of the examples
>> in the rules are important, like "runtime fixes". Spell fixes must be
>> unimportant, but most of the runtime fixes like memory leaks or NULL
>> pointers must be important. I was still a little confused with them.
>>
> 
> Literally, yes. But look at it from a s/w engineering point of view.
> 
> A NULL pointer deref is important, but it is also a *very local* and
> very obvious fix (one that doesn't need extensive testing, one that
> doesn't have effects spread out over many modules that requires great
> amount of thought).
> 
> So such things are trivial bug-fixes.

Yes; it's more the /handling/ of the patch that is "trivial" in a strict
sense.  Bug fixes should usually go through maintainers.  But for fixes
which are obvious == easy to verify, trivial@kernel.org makes sense as a
central point for submitters to turn to, to lower the barrier for
submission.
-- 
Stefan Richter
-=====-=-=== -=== =----
http://arcgraph.de/sr/

Re: Ask for help, about the trivial patches.

[Jesper Juhl]

On 15/07/07, TripleX Chung <triplex@zh-kernel.org> wrote:
> Jesper Juhl wrote:
> > 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
> >
> Thanks for your help.
> But I still have problems.
> Trivial means "of little worth or importance". But some of the examples
> in the rules are important, like "runtime fixes". Spell fixes must be
> unimportant, but most of the runtime fixes like memory leaks or NULL
> pointers must be important. I was still a little confused with them.
>

Think more along the lines of "simple, localized & easy to verify".

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