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@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 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.
