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

Just want to say that the 'libcap' needs for bug reporting are quite
manageable and I find are adequately handled by its component in the
kernel.org bugzilla. If we do migrate to something else, my only
request would be that we support some redirection mechanism - old
commit messages that refer to specific bug URLs can find their way to
wherever the new bug tracker has imported them.

Thanks

Andrew

On Thu, Feb 26, 2026 at 12:45 AM Thorsten Leemhuis <[email protected]> wrote:
>
> 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
>
>