Bug report number for "causes random lockups"

I realise that it is still a generalisation and that to count the actual number of systems
showing a the random lockups would be extremely difficult. And I agree that it is wrong to try
to compute the goodness of a distribution from the loudness of the yells or the prises.

Also I do not want to diminish ubuntu in any way, since it has generally done an excellent
job.

However, the bug reports surely tell us that the number of affected systems is > 0 and that
the regression exists.  

It is clear that regressions can happen. But in some sense you might get a subtle feeling that
there is regression and regression and that one causing the system to suddendly lock and some
of your data to disappear (because you had a virtual machine on at that moment and that didn't
know anything of how to deal with the freeze) is particularly nasty. Also, and more
annoyingly, having linux doing this sort of things tends to rise a sense of revenge in all
your friends who were getting blue screens of death on ME.

But in my opinion the real point here is how to solve the issue as fast as possible and create
conditions so that similar situations do not happen again.  Because the problem is not the
bug, but the management:

1) The bug was known since before hardy release
2) A solution has been known for more than 1 months, but not delivered to anybody
3) The bug appears to be marked as "fix-released". And this is a full acknowledgement of the
bug existence, but is also a funny wording, because the fix was not released
4) And most important, there are many users, like myself, that are now in need to run on
custom kernels that won't likely get any security fix because it takes hours to compile a
kernel.

So, I am only underlining the fact that the policies are not working well here and that the
most notable consequence is a hard-to-quantify but surely non-null rise in the number of
people running unsupported custom kernels on the long term support distro, which is sort of
contradiction.

If 2.6.25 is known to fix issues to some, why not just releasing it in addition (if not in
substitution) to 2.6.24 and why not doing so early?

As a final consideration, understand that there can surely be a rise in the  number of people
involved in the ubuntu kernel.  But that it will always be extremely difficult to find people
willing to x-ray the differences between 2.6.x and the ubuntu 2.6.(x-k) to confine the changes
to backport to ununtu's 2.6.(x-k) to fix it.  Accept that this will always be seen as a most
boring thing to do.  And that most people would just prefer concentrating on making 2.6.x
applicable.