[esgwpl]

This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bug[1] and now this. Fixes for these are on their way as far as I can tell but since the stable team are probably on Christmas vacation it might take a while.

[0] https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906

[1] https://bugzilla.kernel.org/show_bug.cgi?id=210765

[gregkh]

I get a vacation? Hah!

[tuldia]

Every software has bugs, and is easier to criticize than to help. Don't focus on the negativity of HN and keep it up!

Thanks for your hard work, Greg!

[muxator]

Thanks for your work, Greg!

[nasir_hm]

Thank You very much for the hard work you do Greg, You're awesome :D

[gruturo]

Thank you for your hard work Greg, it is very much appreciated.

Merry Christmas/Isaac Newton's Birthday!

[fatboy93]

You should a small vacation sometime ;)

Bugs can always be fixed, mental health can't.

Thanks for all the awesome work Greg!

[esgwpl]

Sorry if my post sounds like a jab, it wasn't meant to be, thanks for your work and Merry Christmas.

[mr_sturd]

Merry Christmas, Greg!

[malikolivier]

Merry Christmas, Greg!

Thanks for all the hard work!

[tremon]

And the fstrim issue: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html

Which triggered an immediate 5.10.1 release: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html

[diegocg]

5.10 is a Long Term Support release that is going to get used by many distros for a long time. Maintainers might have tried (unsurprisingly) to get some interesting features merged.

[est31]

On the bright side updating to 5.10 fixed a regression of a 5.4 to 5.8 kernel upgrade to me. The fix might have been in 5.9 but I only got the idea of upgrading after the 5.10 release.

Anyways, Linux needs some more CI so that such bugs can be found during the RC phase.

[gregkh]

Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?

[fluffy87]

How is the kernel tested ? There weren’t any tests covering any of this ?

[rstuart4133]

> How is the kernel tested ? There weren’t any tests covering any of this ?

Despite appearances, "the kernel" is not a single monolithic thing. There is a about a 100 kloc core (but I haven't looked up that number in years). The rest, hardware drivers, network protocols, file systems, crypto, raid ... bolt on as modules.

Those modules are maintained separate teams. They are as related to the kernel as the phone dialler app is related to Android. The quality of each module is the responsibility of that team, not "the kernel" team. And that applies to testing the module as well.

In a sense, "the kernel" team is more like debian or redhat than developers. What they have done is develop a framework that lets them take bits created and maintained by a cast of thousands, and bolt it together into what appears to be a single coherent thing from the outside. So the answer to "how is the kernel tested" is "it's complex, and not centrally planned".

The other answer is what you are seeing is in fact part of the testing process. Most people use kernels packaged by their distribution. kernel.org releases are more like Microsoft's pre-releases of Windows. Most Debian users for example won't see it until it gets to Debian testing. To get there it must pass through Debian experimental (which is where 5.10 sits now) then sit in Debian unstable without bug reports for a while. Those release names should give you a hint about the anticipated stability of the kernel version. I personally won't use it until it takes another step, which is from Debian testing to Debian backports (which is when it because available to Debian stable users who are willing to risk compatibility issues).

This means that for for most users, 5.10 it's done yet as it has barely begun it's testing regime.