Hi Thorsten, On lun, jun 19 2023 at 11:36:02, "Linux regression tracking (Thorsten Leemhuis)" <regressions@xxxxxxxxxxxxx> 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-kernel-bug-reports-are-ignored/ This is fantastic and a much needed document that should be mandatory training for anyone reporting kernel regressions. IMO this kind of documents should be located in a more prominent place so that it can become a key reference, specially in this case where there's no single right workflow. 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. >> 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. Cheers, Ricardo
