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: > >> Anything else anyone can think of? Any objections to any of these? >> I based them off of Linus's original list. >> >> thanks, >> >> greg k-h >> >> ------ >> >> Rules on what kind of patches are accepted, and what ones are not, into >> the "linux-release" tree. >> >> - It can not bigger than 100 lines, with context. >> - It must fix only one thing. >> - 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? >> - 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. >> - 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. > > Objections - no. Anything else - yes. I would like the requirement: "It > must be obviously correct". > It seems like this would be the primary thing that matters. The rest of them (aside from the "fixes only one thing" and "no cleanups" rules) overlap considerably. > In a hundred lines one can put a lot of tricky code and subtle changes. > For example, if a security problem necessitates a nontrivial change, it > should cause an earlier release of 2.6.x+1 instead of a 2.6.x.y+1. > > Andries - 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/
