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

[Adam Kropelin <akropel1@rochester.rr.com>]

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