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

Konstantin Ryabitsev
2026-04-02T04:59:47Z

On Thu, Feb 26, 2026 at 09:44:32AM +0100, Thorsten Leemhuis wrote:
> 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.

Thank you for starting the thread -- it's been burning a hole through my inbox
and I honestly wasn't trying to ignore it. :)

I've read through it multiple times, and I would like to put forward the
following proposal for bugzilla replacement and bug tracking in general, now
that I have a better idea in my mind.

First, a bit of background info.

# git-bug

The git-bug project aims to keep bug tracking integrated into the git
repository itself. It's not a new project -- it's been around for a while,
though its development has been advancing in spurts. The fundamentals are
sound and the design is robust. It's an active project with ongoing
development:

https://github.com/git-bug/git-bug

# b4 bugs

After some hacking, I managed to do the following things:

1. start using git-bug for b4's own bug tracking
2. integrate git-bug with lore via "b4 bugs", allowing the following:

a) easy way to convert a mailing list discussion into a bug entry
b) keep bugs synced with lore discussions on an ongoing basis
c) use a TUI to manage bugs via "b4 bugs tui"

"b4 bugs" is still in early development, but I have a very small demo here:
https://asciinema.org/a/890396

3. add a simple git-bug viewer into cgit, so bugs can be accessed and viewed
online; e.g. here's one for b4 itself:
https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/

The goal is to introduce a simple way to keep discussions public but also
allow for turning them into actionable bug reports with their own lifecycle
management -- open, closed, needinfo, worksforme, etc.

# new bug reporting

This part remains to be done yet, and I need everyone's input here. I've read
some of the suggestions in this thread and I'm generally aligned with them. In
my mind, bug reporting would go as follows:

- anyone can go to a site like bugs.kernel.org, which will be a simple bug
entry form of the style:

1. tell us what happened
2. attach any files you want to attach
3. tell us how we can contact you (with round-trip verification)

- the report then goes into a review queue that can be pre-processed by an LLM
to help immediately weed out non-actionable items: spam, reports for tainted
kernels, reports for distro kernels, etc. The agent can reply with
cookie-cutter answers to those with a suggested course of action:

1. Please report this to your distro here: {url}
2. Sorry, we can't help you because you're running a binary-only driver
3. This report is for kernel 2.6, what is even happening?

- the agent can also try to figure out which subsystem this report is for
based on the details of the report; this is where various tools to extract
info from dumps would come in handy -- though I expect final human-based
review will be required for this to be not waste people's time

- finally, the report can then either be mailed straight to the subsystem
maintainers using MAINTAINERS info, or go into another holding queue to be
reviewed by a human caretaker -- I'm happy to discuss details here

- the maintainers can their either handle this directly via email without
turning the report into a bug entry, or they can use the above described
tooling to manage the bug report's lifecycle via git-bug/b4 bugs

This is my "bird's eye view" proposal, and I'm happy to now refine this and
find a solution that would be actually useful to maintainers.

Best regards,
--
KR