Re: [RFQ] Rules for accepting patches into the linux-releases tree

Adam Kropelin
2005-03-06T20:08:57Z

Andres Salomon <dilinger@voxel.net> 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