Re: kernel.org tooling update

[Thorsten Leemhuis <linux@leemhuis.info>]

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/aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info/



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