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

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

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