Hi! TLDR: Core Linux kernel developers are unhappy with the state of bugzilla.kernel.org; to improve things I plan to change a few important aspects of its configuration, unless somebody comes up with better ideas to tackle current problems: (1) Create a catch-all product making it totally obvious to submitters that likely nobody will look into the ticket. (2) Remove or hide all products & components where the subsystem didn't fully commit to look into newly submitted reports. (3) Change the text on the front page to make it clear that most kernel bug reports need to be sent by mail. I recently brought the state of bugzilla.kernel.org up for discussion on the kernel summit and the kernel maintainers summit in sessions about my regression tracking efforts. Long story short and rough: in both sessions attendees were quite unhappy about the current state and wanted things to change for the better. As I brought that topic up, I guess I have to get things rolling now. But before getting into the details, a quick & rough reminder about the current state of bugzilla.kernel.org: * The server and the software running on it are well maintained by the the infrastructure team (Konstantin et al.); many thx for this! * Products, components, default assignees, et al. OTOH are heavily outdated, incomplete, or wrong: maintaining this is not the job of the infrastructure team and nobody else has stepped up to take care of this (for a few more details see: https://lore.kernel.org/lkml/20220420163223.kz32qomzj3y4hjj5@nitro.local/). * To the best of my knowledge bugzilla.kernel.org was never really sanctioned as the official place to report all sorts of kernel bugs: only 20 (most of them from the area of ACPI/PM and PCI) out of ~2500 entries in MAINTAINERS currently tell users to report issues there; most other subsystems just mention email contacts, a few (like the DRM developers) point reporters to external bugtrackers. * Developers of subsystems committed to the bug-tracker afaics usually react to reports submitted in bugzilla.kernel.org. A few other developers & subsystems keep an eye on reports, too; some do this directly, others rely on bugzilla forwarding reports for certain products/components by mail to the subsystem's mailing list. Quite some or a lot of tickets are not forwarded to any developer or mailing list at all. * In the end lots of bug and regression reports (even good ones!) never get a reply from a developer, as a brief analysis of mine showed (https://lore.kernel.org/lkml/6808cd17-b48c-657d-de60-ef9d8bfa151e@xxxxxxxxxxxxx/ ). I at least currently try to work a bit against this by briefly looking at each new report and forwarding any by mail that looks like a regression worth forwarding (I ignore everything else). Artem S. Tashkinov also looks into some (all?) reports and tries to help reporters. The sessions on kernel summit and the kernel maintainers summit discussed the current state only for a few minutes. It's hard to summarize these discussions, but let me try to mention the aspects that are important for now: * In both sessions members of the audience seemed pretty unhappy to me about the current state of things. * In the kernel summit sessions (recording: https://youtu.be/e2SZoUPhDRg?t=5370 ) Len Brown stated that he and fellow ACPI/PM developers rely on bugzilla.kernel.org and would need some replacement if it's decommissioned. * On the maintainers summit (see the last section of https://lwn.net/Articles/908324/ for a brief write-up that coined the term "Bugzilla blues") someone brought up the upstream development of bugzilla the software seems to be dead; there was not even one strong advocate for bugzilla.kernel.org and the general vibe tented into the direction of "let's get rid of it". But it was also mentioned that bugzilla.kernel.org does something useful which will need a replacement: a place where reporters can upload big files needed for debugging problems. In the end that made me settle on this plan of action: 1. Finding a replacement for bugzilla will take a while, so for now let's try to reduce some of its aspects that are bothering people: 1a. Create a new product/component that can act as a catch-all bug, but makes it pretty clear that nobody might see the report because it's not forwarded to anyone. People can use it to upload files for debugging and link to them in mailed reports. People unable or unwilling to report issues my mail (see 1c) could use it to submit issues, too. The outcome then is the same as before, but at least people were told upfront about the likely outcome; it also gives users a chance to help each other or to coordinate before properly reporting an issue. 1b. Go through the list of products and components and hide or remove *all* where the subsystem didn't fully commit to look into newly submitted reports. Minimum requirements to remain listed will be along these lines: subsystem mentions bugzilla.kernel.org in MAINTAINERS or a developer listed in MAINTAINERS is one of the default assignees in bugzilla. Subsystems where bugzilla forwards mails to a mailing list can remain listed as well, if the recent history shows the developers look into newly filed bugs. I'll use my best judgment in the transition process and will file "anyone listening?" bugs if in a doubt. 1c. Make it obvious on the front-page of bugzilla.kernel.org that most kernel developers want bug reports to be submitted by mail; mention the subsystems that accept reports there and point to the catch-all bug (see 1a) as a last straw. 2. See if everybody is happy with the new state for the time being; if not further fine-tune things or speed up step (3). 3. Work out what we want as replacement. Anyone any comments on this or helpful ideas how to make things even better? Otherwise, I'll in a week or two get down and start working on realizing the points listed under step (1). Ciao, Thorsten
