4 ms·

Comment rom "Helping Out with LTS Kernel Releases"[0]: "I find it amusing that the answer to "how can I help test" is "that people test the -rc releases when I

by lumpa 6y ago

Comment rom "Helping Out with LTS Kernel Releases"[0]: "I find it amusing that the answer to "how can I help test" is "that people test the -rc releases when I announce them, and let me know if they work or not for their systems/workloads/tests/whatever". No smoke tests, no automated tools, no suggested workloads, no fuzzing, just "fool around and report back". There probably are lots of kernel testing tools around, but you wouldn't learn that from the linked article." It seems to be conscious choice, to the point of developers stating that "the process works". Which, looking at the results, it does seem to work. But wouldn't it work better with more tests, easily run by users wanting to help? I mean, if a downstream patch in related code regresses the issue, is there a new test added with this fix that would catch that? Edited to add: it seems that the situation is changing for the better, with gregkh saying in a comment: "`make kselftest` seems to do what you want today, if there are any gaps the kernel developers are glad to take more tests." [0] https://news.ycombinator.com/item?id=26021962 https://news.ycombinator.com/item?id=26021962 [1] https://lwn.net/Articles/848352/ https://lwn.net/Articles/848352/

richardwhiuk 6y ago
I suspect lots of downstreams kernel developers do run smoke tests, automated tools, workloads and fuzzing. It's just done individually, with each person hitting their own niche, and without a single all-powerful CI pipeline that's visible.
raverbashing 6y ago
Several people booting their favourite distro with the new kernel stresses a lot of areas at once. Yes, it's a manual test, but it "does the job" (or 99% of it at least)
- lumpa 6y ago
  It would do an even better job if the user could easily increase coverage or depth of that stressing and check against known issues (regressions). Maybe `make kselftest` is the way to go. But it might be worth creating an easy way for people to help test the kernel, something like Debian popcon meets CPU-Z benchmarks.

by lumpa 6y ago

richardwhiuk 6y ago

I suspect lots of downstreams kernel developers do run smoke tests, automated tools, workloads and fuzzing. It's just done individually, with each person hitting their own niche, and without a single all-powerful CI pipeline that's visible.

raverbashing 6y ago

Several people booting their favourite distro with the new kernel stresses a lot of areas at once. Yes, it's a manual test, but it "does the job" (or 99% of it at least)

lumpa 6y ago
It would do an even better job if the user could easily increase coverage or depth of that stressing and check against known issues (regressions). Maybe `make kselftest` is the way to go. But it might be worth creating an easy way for people to help test the kernel, something like Debian popcon meets CPU-Z benchmarks.