Hi Konstantin! The bugzilla.kernel.org situation still bugs me, as I every few days see a report or two that at least from a quick look seems valid and good, but nevertheless is ignored (for a recent example see https://bugzilla.kernel.org/show_bug.cgi?id=216736 ). I can't help each of them individually. Hence as a stopgap measure I'm considering adding a comment with a predefined statement to any reasonable Linux kernel bug report I notice (I look at most of them anyway to check for regressions, so quickly adding a comment is not that much trouble for me). Find the proposed text for the predefined statement below. It's supposed to link to a page on the web with even more details; the proposed text for that is below, too. Is it okay for you if I start doing this? Are the texts okay from your perspective, too? I tried to be careful with my wording, but maybe I didn't find the right tone in some places or forgot something important. I'm asking as I don't want to undermine your efforts at all, I just want to enable users to help themselves *now* until your efforts to improve the situation are in place. Ciao, Thorsten ################# propose statement to be used as comment Many thanks for your report. There is something important you might not be aware of(¹): some, many, or most kernel bug reports submitted here will never reach suitable developers. You hence might not get any replies from them here. If that’s the outcome after roundabout a week, resubmit your report to the place where the developers of the subsystem in question expect reports; the document https://docs.kernel.org/admin-guide/reporting-issues.html explains how to find that place in the section "Check where you need to report your issue". Please add a comment here when you go down that route. There are plans to improve things over the next few months, as explained here: <fixme: link to the page in the web with below text>; that page also provides a few additional details why things happen to be as briefly outlined above. (¹) Please don't shoot the messenger, I’m quite unhappy about this state of things myself. But they are outside of my control. And I think it’s better to tell you about the situation now, as you otherwise might be waiting weeks or months for a reaction here that might be pretty unlikely to happen in the first place. ################# text for a webpage # On the state of bugzilla kernel ## TLDR Some, many, or most bug reports submitted in bugzilla.kernel.org will never reach suitable kernel developers. If you don’t receive a reply from them, you might want to re-submit your report to the place where developers actually expect bug reports. There are plans to improve this situation – a situation which came into being due to various unfortunate developments a long time ago. ## What this is about An unknown quantity of bug reports submitted to bugzilla.kernel.org will never reach kernel developers that take care of the code that might cause the particular issue. That’s among the reasons why some, many, or most of those reports never get a reply. This page will explain what you can do in that case, what is planned to improve the situation, and how this state of things came to be. ### What can I do if my report in bugzilla.kernel.org is ignored If your bug report in bugzilla.kernel.org within a week receives no replies at all or none from developers working on the code in question, consider re-submitting your report to the place where those developers expect reports; how to find that place is explained by the document “Reporting issues” (https://docs.kernel.org/admin-guide/reporting-issues.html) in the section “Check where you need to report your issue”. Please add a comment to your report in bugzilla when you go down this route. Side note: you might also want to read and follow the “Reporting issues” document as a whole, as that will avoid many other pitfalls that might lead to your bug report being ignored. Quite a few or many kernel developers for example only handle reports about issues with the latest mainline codebase or the latest stable release; reports about issues in longterm (aka LTS) kernels or any version more than two weeks old thus might not be acted upon. The same fate often happens to reports about issues with distro kernels, as most of them are heavily modified or enhanced, which might cause the issue you face; that’s also why reporting issues with kernels that use any drivers not build straight from the Linux kernel sources (like those from Nvidia) are often ignored and thus a waste of time. ### What is planned to improve the situation Konstantin Ryabitsev plans to realize his proposal from early October 2022: https://lore.kernel.org/lkml/20221004175354.bfvg3vhfqch35ib5@meerkat.local/ For the backstory on how that proposal came into being, see the following text and the sources it links to: https://lwn.net/Articles/910740/ ### Why are developers free to ignoring bug reports in bugzilla.kernel.org Because participation has always been and still is optional for the developers of the Linux kernel. That's because well-intended people a long time ago thought Linux kernel development would benefit from having a bugtracker and set up bugzilla.kernel.org; they did that despite the fact that many core Linux developer's beforehand had made it clear they didn't like or even opposed the idea -- and thus were unwilling to participate. Many components and products bugzilla.kernel.org lists for the Linux kernel thus not even initially had developers on board that looked at newly submitted bugs. The idea was to have volunteers for these areas that checked the reports and forwarded the good ones to the actual kernel developers – but that never really worked out for real on a large scale. Many after some time also left without any successors. This is why some bug reports are never forwarded to suitable kernel developers. The people who set up and cared about the bug tracker over time moved on to other endeavors. But by then the bugtacker could not simply be decommissioned, as a tiny number of kernel developers and the subsystems they maintained had started relying on it for internal development. In the end as of this writing in 2022 around 20 out of 1500 maintainers and subsystems listed in the kernel's MAINTAINERS file officially committed to handle bug filled in bugzilla.kernel.org (mainly those from the areas of ACPI, Power Management, and PCI). A few other subsystems and an unknown number of individual developers keep a close or loose eye on it as well; there are also some that participate when pointed to reports about their code. But in the end some or many kernel developers don’t care about it at all and never receive copies of bugs occurring in the they maintain.
