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

Andres Salomon
2005-03-06T17:11:37Z

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