Yes, testing is desired --- in order to shake out bugs that are not
manifest on the developer's systems. Remember that the kernel is a
special program in which there are many classes of bugs that can only be
reproduced on special hardware and/or with special workloads.
Alas, there are not only new bugs in new features but also new bugs in
existing features, a.k.a. regressions. But like new bugs, many
regressions can alas not be found by the developers themselves on their
test systems.
You mentioned two particular regressions in your initial posting. Do
you have suggestions how they could have been prevented in the first
place? Or how they could have been handled better than they were?
Do you see subsystems of the kernel in which regressions are not taken
as seriously as in other ones?
2.6.35 will only be better if this (gradual) change of procedure means
that -rc kernels are going to be tested more and new bugs are going to
be found and fixed quicker in the -rc phase than before. And 2.6.36+
will only be better if the stricter post -rc1 merges do not motivate
developers to put even more hastily assembled under-tested crap into
their pre -rc1 pull requests than they already do.
[PS: 2.6.34 works very well for me, as most 2.6.x releases do.]
[PS2: When on lkml, please use reply-to-all, not reply-to-list-only.]
--
Stefan Richter
-=====-==-=- -=== -=-==
http://arcgraph.de/sr/
--
