i think this heavily varies per subsystem.
v2.6.24-rc was pretty bad due to the sglist design bug that crept in and
that kept most of the IO hackers busy for a few weeks, while testsystems
kept crashing and no progress was made on _other_ bugs. v2.6.24 early
rc's were also marred by half-cooked networking patches messing up
bisectability. I've seen a number of testers give up on that alone.
There was an unusually high flux of networking fixes throughout v2.6.24,
up to the very last day before the release.
Since it's Friday already, i put the blame for that on all the
subsystems that do not develop on lkml! :-)
It is _very_ hard for us to judge the stability and sanity of a
subsystem (and the risk factor of upcoming features!) if it's not
developed on lkml. Observing the bugs alone helps in getting a picture,
but it does not help the testers of early -rc's: it is a few
weeks/months after the fact and hence too late. We need to be able to
observe the development activities, but that's hard with all these
detached development lists. (Not only hard, it is in fact impossible,
given the sheer number of mailing list addresses in MAINTAINERS. I know,
i tried it.)
so -rc stability is usually a function of the feature/fix ratio of a
given subsystem's changes for a kernel, and those are very hard to
predict if they are not done on lkml. Getting good -mm coverage for the
subsystem git trees helps quite a bit as Andrew does a heroic job
herding all the cats, but still there's way too much 'surprise factor'
in the git merges and all the hidden development that is not directly
visible on lkml. The 'surprise factor' is not even come mainly from
combining all the trees together (that is relatively easy), it is in the
cumulative risk factor that is hard to get right due to development not
always being done on lkml.
Case point from arch/x86: everyone who follows lkml could have predicted
it from the PAT development discussions that PAT is simply not ready
yet. We deferred it to v2.6.26, but had we tried to cram it into v2.6.25
and had it broken boxes left and right, we'd rightfully be confronted
with all the existing lkml track record that suggested bad PAT related
problems and predicted the outcome. For subsystems that do not develop
on lkml, no such lkml track record exists and the danger of introducing
bad patches and ruining early -rc's increases.
Ingo
--
