Re: kernel.org tooling update
Thorsten Leemhuis <[email protected]>
| Newsgroups | dev.linux.lists.ksummit,dev.linux.lists.regressions |
|---|---|
| Message-ID | <[email protected]> |
Lo! Thx for the update, much appreciated! On 12/10/25 05:48, Konstantin Ryabitsev wrote: > ### Bugzilla > > It may be time to kill bugzilla: Thx for bringing this up, as I a few months ago again looked somewhat closer at the state of how well our bugzilla is working for the core kernel. I didn't post the analysis in the end, but to me it looked like the state of things was round the same as it was three years ago -- when it wasn't working well, which was among the reasons why we came close to abandoning bugzilla for kernel bugs[1]. [1] for those that don't remember, see https://lwn.net/Articles/910740/ and https://lore.kernel.org/all/[email protected]/ > - despite periodic "we're not dead yet" emails, it doesn't appear very > active > - the upgrade path to 6.0 is broken for us due to bugzilla abandoning the > 5.2 development branch and continuing with 5.1 > - question remains with what to replace bugzilla, To me it looks like most subsystems don't care much or at all about bugzilla.kernel.org. This made me wonder (and maybe you could gather some opinions on this in Tokyo): * How many kernel subsystems have a strong interest in a bug tracking solution at all[2]? And how many of those might be happy by using some external issue tracker, like those in github (like Rust for Linux, thesofproject, and a few others do), gitlab (either directly, like apparmor, or self-hosted, like the DRM subsystem)? * Does the kernel as a whole need a bug tracking solution at all to receive reports? We for now require email for patches, so why not for bugs as well, unless a subsystem really wants something (see above)? [2] Some numbers: $ for i in "" mailto bugzilla github gitlab; do echo -n "Searching for '^B:.*${i}': "; grep -c -E "^B:.*${i}" MAINTAINERS; done Searching for '^B:.*': 70 Searching for '^B:.*mailto': 12 Searching for '^B:.*bugzilla': 23 Searching for '^B:.*github': 17 Searching for '^B:.*gitlab': 11 > but it's a longer discussion topic that I don't want to raise here; Would like to be involved there. > it may be a job for > the bugspray bot that can extend the two-way bridge functionality to > multiple bug tracker frameworks FWIW, development of my regression tracker (regzbot) and me using it to track regressions nearly stalled but is slowly restarting. Would be good if we could work together here, as there is some overlap -- and regression tracking afaics is something that a lot of people want and consider important. And regzbot is already capable of monitoring reports in various places (lore, gitlab, github, bugzilla); so if we decide that we don't need a tracker for the kernel as a whole, it might already do nearly everything for the bugs where tracking really helps a lot. Ciao, Thorsten