slowly decommission bugzilla? (was: Re: kernel.org tooling update)

On 12/10/25 05:48, Konstantin Ryabitsev wrote:
>
> ### Bugzilla

Lo! I wonder if we should slowly and publicly start decommission
bugzilla in areas where it's not working well today. I have a few
reasons for that:

> It may be time to kill bugzilla:
> 
>     - 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

* It looks like we will decommission Bugzilla anyway, and a replacement
is afaics likely quite a while (years?) away -- so what is there now
will likely be kept running for a while.

* Bugzilla at the same time since a few years now is known to not
working well, as many reports (including good ones) never get a reply --
among others because the list of products/components is not kept in
sync, so many reports never reach the right developers (see
https://lwn.net/Articles/910740/ and the second and third links there
for the more complete backstory; things are afaics round about the same
from what I see when occasionally looking at bugzilla for regression
reports worth forwarding by mail – and that is really hard to watch, as
it feels bad to see people spending time on something that is most
likely not leading to anything).

* Statements like "Dear Deity, I do wish kernel MM bugzilla would just
go away. Sigh." (akpm recently in
https://lore.kernel.org/all/[email protected]/)

"Slowly start publicly decommissioning Bugzilla" could look like this:

* Prevent new bugs from being submitted against products/components
where the developers/subsystems are not engaging in Bugzilla (either
directly or through replies by mail). That would make people like akpm
happy afaics. I'm willing to help with talking to subsystems and
adjusting settings in bugzilla.

* Create a new front page that tells users that they most likely are in
the wrong place. The text could look like this:

"""
Welcome! Note: The kernel.org bugzilla is slowly being decommissioned!

This bug tracker is a kind of failed experiment, which at the same time
still is useful sometimes and thus for now kept alive. Due to this and
how vendors utilize the Linux kernel, you are most likely in the wrong
place to report your bug.

To find the right place, check the Linux kernel's [MAINTAINERS
file](https://docs.kernel.org/process/maintainers.html). Most of the
time it will tell you to report bugs by email with some mailing lists in
CC. Bugs with all the kernel's modern graphics drivers, on the other
hand, [must be submitted to a Gitlab
instance](https://gitlab.freedesktop.org/drm) – and a small number of
subsystems want reports in issue trackers of dedicated Github projects
or this bug tracker.

For more details on this and reporting Linux kernel bugs in general, see
the [official step-by-step guide on reporting
issues](https://docs.kernel.org/admin-guide/reporting-issues.html#step-by-step-guide-how-to-report-issues-to-the-kernel-maintainers).
It covers all the important aspects, including one that is often missed:

In case somebody else compiled your Linux kernel, you most likely have
to report bugs to said vendor – like Linux Mint, Red Hat, Ubuntu, or
SUSE. That is because the majority of the Linux developers only care for
bugs occurring with kernels built from Linux sources that are pristine
(aka "vanilla") or nearly so. Kernels using independently developed
kernel modules are therefore just as unsuitable for reporting bugs upstream.
"""

Sigh, too much text, but you get the idea.

Ciao, Thorsten