Re: Linux 2.6.21

From: Bill Davidsen
Date: Thu Apr 26 2007 - 13:23:38 EST

Adrian Bunk wrote:
On Wed, Apr 25, 2007 at 08:29:28PM -0700, Linus Torvalds wrote:
So it's been over two and a half months, and while it's certainly not the longest release cycle ever, it still dragged out a bit longer than I'd have hoped for and it should have. As usual, I'd like to thank Adrian (and the people who jumped on the entries Adrian had) for keeping everybody on their toes with the regression list - there's a few entries there still, but it got to the point where we didn't even know if they were real regressions, and delaying things further just wasn't going to help.

Number of different known regressions compared to 2.6.20 at the time
of the 2.6.21 release:

Number of different known regressions compared to 2.6.20 at the time
of the 2.6.21 release that were first reported in March or earlier:

Number of different known regressions compared to 2.6.20 at the time
of the 2.6.21 release with patches available at the time of the 2.6.21 release [1]:

What I will NOT do:
Waste my time with tracking 2.6.22-rc regressions.

We have an astonishing amount of -rc testers, but obviously not the developer manpower for handling them.

If we would take "no regressions" seriously, it might take 4 or 5 months between releases due to the lack of developer manpower for handling regressions. But that should be considered OK if avoiding regressions was considered more important than getting as quick as possible to the next two week regression-merge window.

But releasing with so many known regressions is insulting for the many people who spent their time testing -rc kernels.

Without someone holding Linus feet to the fire the next release may be a real POS. I think you have done the perfect job, identifying the show stoppers, quantifying the obscure and minor regressions, and serving to give testing targets as purported fixes are applied.

I don't think you should judge your work by leaving some targets for -stable and 2.6.22, but rather from the number of problems you detected, documented, and caused to be addressed.

If it were my week to be God, I would insist that the rcN to final step was regressions-only, and that all regressions be classified as (a) acceptable results of changes to fix other problems, (b) must be fixed before release, or (c) obscure enough to tolerate for a short time, must be fixed in stable and mainline before N+1 release.

Measuring releases or your own value against perfection is thankless!

Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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