Not a release cycle length problem

Not a release cycle length problem

The problem, as I see it, was that things got to the point where the entire community was waiting for no more than 14 developers to debug things that nobody else had the appropriate knowledge to work on. (And some of these developers were waiting for bug reporters to get back with more information, too). And adding more people to debugging a small number of regressions would just slow down the process (c.f. Mythical Man Month). The only application of additional developer effort I could see actually being helpful at the point when 2.6.21 was released would be if Alan Cox could be convinced to fix serial port drivers (since he's got experience in that area he's not using).

I think, actually, that 2.6.22 wasn't forked soon enough; I think that the delay of the merge window meant that too much code was sitting in development without testing, leading to a drop in the quality of code appearing in -mm (which Andrew commented on for the 2.6.22 merge plans). On the other hand, I don't think the code tagged as 2.6.21 deserved the penguin pee. The real issue is that 2.6.x isn't released according to a release engineering process which creates stable results. Between the last -rc and 2.6.21, non-obvious patches were merged that added regressions. If this sort of thing happens, having more -rcs and spending more time couldn't possibly help. The solution, I think, would be for Linus to release even earlier, but have each series go through a period run by the -stable team with -stable rules before a final release that gets a penguin-pee version number.