On 19.06.23 13:53, Ricardo Cañuelo wrote:
On lun, jun 19 2023 at 11:36:02, "Linux regression tracking (Thorsten Leemhuis)" regressions@leemhuis.info wrote:
BTW and JFYI (as you earlier said my docs helped you): the aspect "who is responsible to handle this regression: the regular maintainer or the stable team?" that came up earlier with this report lead me to sit down and write a text called "Why your Linux kernel bug report might be ignored or is fruitless" I published here:
https://linux-regtracking.leemhuis.info/post/frequent-reasons-why-linux-kern...
This is fantastic
Feels really good to hear this, as it was a lot of work that involved a lot of rewriting...
Nevertheless: let me know, if there is something where you think "this doesn't feel right", "this could be clearer", "I don't understand this", or something like that.
and a much needed document that should be mandatory training for anyone reporting kernel regressions.
Well, bugs in general I'd say.
IMO this kind of documents should be located in a more prominent place
Yeah, but where? I wondered if I should ask Jonathan if this is something for lwn.net, but something in me says it would be a odd fit.
Maybe with a bit of effort of us all we can improve the situation so that bugs and regression reporting and tracking in the kernel becomes a much more streamlined process.
I'd really like to work more on that, but this regression tracking thing is a time sink. And regzbot still needs quite a few improvements as well. :-/
Would help if I finally would figure out how to use "git clone" to create a clone or two of myself. ;)
That leads to the question: should we spend our time on it?
As expected there wasn't any progress (at least afaics). [...] Ricardo, how would do you and Kernelci folks feel about ignoring this?
I can't speak on behalf of the KernelCI people, but this being something that isn't failing in mainline and considering that the stable release where it happened was very close to EOL puts this in the low-priority category for me. Fixing bugs can become a quite expensive task in terms of time, and I'm try to factor in the impact of the fix to make sure the time spent fixing it is worth it. In other words, making test results green just for the sake of green-ness is not a sound reason to go after the failures. We're trying to improve the kernel quality after all, so I'd rather focus on the regressions that seem more important for the kernel integrity and for the users.
Well said. It's similar for regression tracking, hence let me remove it from the list of tracked issues
#regzbot inconclusive: seems nobody is motivated enough to work on resolving this issue found by KernelCI (see lists for details).
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.