Andres Salomon <[EMAIL PROTECTED]> wrote: > On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote: > > On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote: > >> - It must fix a real bug that bothers people (not a, "This could be a > >> problem..." type thing.) > > An obvious fix is an obvious fix. It shouldn't matter whether people have > triggered a bug or not; why discriminate?
Because the sucker tree is purposely driven by real bug reports, not by developers who happen across a theoretical problem while traversing the code. If users aren't hitting it today, the fix can wait for 2.6.n+1. > >> - It must fix a problem that causes a build error (but not for things > >> marked CONFIG_BROKEN), an oops, a hang, or a real security issue. > >> - No "theoretical race condition" issues, unless an explanation of how > >> the race can be exploited. > > I disagree w/ this; if it's an obvious fix, there should be no need for > this. Either it's a race that is clearly incorrect (after tracing through > the relevant code), or it's not. The sucker tree is not a dumping ground for every fix under the sun (even obvious ones). It's for solving problems hit by real users, right now. > >> - It can not contain any "trivial" fixes in it (spelling changes, > >> whitespace cleanups, etc.) > > This and the "it must fix a problem" are basically saying the same > thing. No. There's an important distinction and the key word is "contain". This rule specifically forbids patches that do fix a real problem but _also_ contain unrelated trivial changes. See "setup_per_zone_lowmem_reserve() oops fix" for an example of a patch that could theoretically be rejected due to this rule. --Adam - 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/
