>> Maybe some QA period before the release might help, but who would
>> care? (Especially under the situation where everybody has own x.y
>> stable tree?)
>
> Hopefully people tracking the upstream stable trees would be throwing
> any pre-release stuff into their QA processes before it was officially
> released upstream, though I'd not count on it.
Linux testing is (realistically) done by inflicting changes on gradually wider
sets of end users.
We go through these stages (possibly a couple of extra steps where maintainer trees
are nested)
1) Author of a patch tests on their own machine (and perhaps a few others)
2) Patch is posted. A few more people grab and test.
3) Patch is applied to a maintainer tree, which is slurped into linux-next.
A few hundred brave folks now have this patch in their binary, but most extra testing
is purely accidental. These users aren't running focused tests on the area touched
by the patch.
4) Patch is pulled by Linus. Pretty large jump in the number of users running the code
so we start to get good breadth of testing on different machines with different sets
of CONFIG options under varying workloads.
5) Linus releases a final 3.x version - another substantial bump in the number of testers
because there are lots of people who wait for "release" quality kernels.
6) Fedora, Ubuntu etc. use this 3.x kernel as basis for a release. Probably two or three
orders of magnitude more users (but only a fraction of their problems are reported
back to LKML).
Thus code does get more and more QA - the longer you wait before taking a patch the
lower the risk that it has some unintended side-effect or outright bug . But of course
you are vulnerable in this whole period to whatever issue the patch was actually
trying to fix. So you have a classic tradeoff.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html