Releasing with high number of regressions?

Calling this particular transition "the release", as opposed to calling other versions that is a bit of an arbitrary decision. The direct effect of Linus doing this is that the change acceptance policy switches from the "late rc" rules to the "stable" rules. It makes a lot of sense to make this change with a certain number of regressions, because the "late rc" rules aren't really sufficiently tight to keep new regressions from arising. And Linus can't adopt "stable" rules for the mainline in the period shortly before the release, because the stable rules require changes to be in the mainline before they can be added to the stable branch.

There's also the fact that kernels don't get as much adoption (and therefore, as widespread testing) before whatever is marked as "the release" as they get after, which means that there's a point where most of the regressions in a kernel aren't being worked on because they haven't been discovered yet. There's little point in delaying a release until *all* of the regressions haven't been discovered yet. Also, when Linus does a release, it's a good time for developers of features which are taking several cycles to stabilize to merge mainline into their work (if that happens too frequently, their history gets messy and they start needing to include fixes for other people's bugs in order to keep working), which means that there's a segment of developers who only run a kernel derived from 2.6.x-rcN on the development systems when 2.6.x is released, which in turn means that producing a 2.6.x-rcN-derived kernel with few regressions depends on getting 2.6.x out first.

In general, you get good long-term quality and steady improvement by having a mainline frequently open for bleeding-edge development with a trailing edge that picks up regression fixes before it picks up new features.