Re: [RFQ] Rules for accepting patches into the linux-releases tree
From: Adam Kropelin (akropel1_at_rochester.rr.com)
Date: 03/06/05
- Previous message: Dominik Brodowski: "Re: Unsupported PM cap regs version 1"
- In reply to: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Next in thread: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Reply: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 6 Mar 2005 15:10:50 -0500 To: Andres Salomon <dilinger@voxel.net>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Dominik Brodowski: "Re: Unsupported PM cap regs version 1"
- In reply to: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Next in thread: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Reply: Andres Salomon: "Re: [RFQ] Rules for accepting patches into the linux-releases tree"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
