lkml.org 
[lkml]   [2003]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.0-test9

On Sat, 25 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> Hmm... Do you count the stuff like "driver foo dereferences after
> kfree()" as major when fix is to reorder two consequent lines in said
> driver?

The smaller and more obvious the change is, the less critical the bug has
to be.

If it's a really unlikely bug, and fixing it requires some fundamental
changes, I consider the fix to be potentially more dangerous than the bug.
But if the fix is re-ordering two lines in really obvious ways, and the
bug itself is potentially nasty, the fix obviously goes in.

It's a matter of balancing the potential downside of a fix (which is
unknown, but tends to be relative to how big the patch is) with the
benefits (which should be known).

> Proposed rules:
> a) all changes must be local and separate. Anything that affects
> more than one place is either splittable, in which case it's more than
> one change, or doesn't belong there.
> b) chunks stay separate until they go into the main tree. IOW,
> they are fed one by one (when merges are OK) and they become separate
> changesets.
> c) all chunks must be mergable into -STABLE. IOW, the rules are
> the same as for 2.6.1 - as far as merging into that tree is concerned,
> we are not in -RC anymore.

Yes, but at this point I actually want to be _more_ strict that just (c).

There are things that I bet Andrew will be willing to apply to -STABLE:
things like architecture updates etc that clearly fix stuff. But right now
I want to avoid even that kind of noise: if it doesn't clearly help
_testing_ of stability, I'm just not interested at this point.

So for example, in the last week I just dropped some S390 updates without
even looking at them. It was too late - and even if they fix bugs, I don't
see that applying those patches simply would matter for 2.6.0 any more.

So for example: I am pretty happy with how the size of the -test8 and
-test9 patches have been shrinking, but even -test9 was big enough that I
couldn't say that we're clearly "asymptotically approaching a stable
kernel". At some point "noise patches" are bad if only because they make
it less clear what the general status of the tree is.

In particular, if the 2.6.0-test10 patch is just 30kB compressed, and I
can just page through it with "less" and see that every single small part
of the patch was pretty clear and not something really scary, I'll be a
_lot_ happier about passing the thing off to Andrew. In contrast, if the
patch is full of stuff that isn't really obvious, I'm going to be less
happy, and worry more about what the side effects are.

Linus

-
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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.203 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site