Re: Linux 2.6.21

From: Stephen Clark
Date: Thu Apr 26 2007 - 15:11:37 EST

Krzysztof Halasa wrote:

Adrian Bunk <bunk@xxxxxxxxx> writes:

Look at the facts:
8 out of 14 regressions in my current list were reported in March or earlier.
And for many regressions fixed it took several weeks until debugging by a kernel developer was started.

We do not lack testers for getting bug reports quickly.
We lack developer manpower for debugging the many regression reports.

Quite possible, given the (very) limited range of the bugs. Most people
just can't debug them.

This isn't IMHO fundamentally wrong, and releasing a ".0" kernel with
known problems isn't fundamentally wrong either.

What is missing is easily accessible KNOWN_PROBLEMS information for
released kernels. While I think your work documenting etc. known
regressions is a very good thing, publishing it with the released
kernels (certainly .0 and next stable releases, perhaps "quite stable"
rc versions as well) would be ideal.

A pressure for fixing the bugs is, obviously, the other very good thing.

2.6.20 was actually really good. Yes, it had some regressions, but I do believe that it was one of the least buggy releases we've had. The process _worked_.

I the process worked with 2.6.21 as well. Obviously no two releases
are equal, one has to be better than the other.

I'm not satisfied with the result, and the world won't stop turning when I'm not tracking 2.6.22-rc regressions.

Anyway, I and many others are satisfied with the result. I think it's
one of the few "quite recent" things which are a great improvements.
Other such things are using that weird git thing :-) and perhaps the
most important - the length of devel cycle under control (I mean the
lack of "2.5 series" thing).

But I am not happy with the current state of released kernels.

We've got stable series.
With KNOWN_PROBLEMS information, sysadmins can decide if they can
safely upgrade to .0 or if they have to wait for .123. Pressing
the responsible people to fix the problems in .123 (would) help
it greatly.

The biggest problem I see is that developers want to make
improvements in an area, like ide, but they don't seem to
look at the old code and make it sure the new code supports
everything the old code did. This causes hardware that used
to work to not work, or work in a degraded fashion.

My $.02


"They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin)

"The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at