Re: Ask for help, about the trivial patches.
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, [EMAIL PROTECTED] makes sense as a central point for submitters to turn to, to lower the barrier for submission. -- Stefan Richter -=-=-=== -=== = http://arcgraph.de/sr/ - 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/
Re: Ask for help, about the trivial patches.
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, [EMAIL PROTECTED] makes sense as a central point for submitters to turn to, to lower the barrier for submission. -- Stefan Richter -=-=-=== -=== = http://arcgraph.de/sr/ - 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/
Re: Ask for help, about the trivial patches.
On 15/07/07, TripleX Chung <[EMAIL PROTECTED]> 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 <[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 > 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 <[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/
Re: Ask for help, about the trivial patches.
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 <[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 >> > 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. - 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/
Re: Ask for help, about the trivial patches.
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 <[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 > 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 - 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/
Re: Ask for help, about the trivial patches.
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 [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 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 - 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/
Re: Ask for help, about the trivial patches.
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 [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 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. - 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/
Re: Ask for help, about the trivial patches.
On 15/07/07, TripleX Chung [EMAIL PROTECTED] 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 [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 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 [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/
Re: Ask for help, about the trivial patches.
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/
Ask for help, about the trivial patches.
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. - 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/
Ask for help, about the trivial patches.
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. - 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/
Re: Ask for help, about the trivial patches.
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/
