[resent with the right ksummit list in CC] On 29.09.22 13:19, Thorsten Leemhuis wrote: > 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
