Re: slowly decommission bugzilla?

[Thorsten Leemhuis <linux@leemhuis.info>]

On 4/2/26 06:59, Konstantin Ryabitsev wrote:
> 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

Seems we'll get there faster. Thx Konstantin!

>> -- 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. :)

No worries, I from social.kernel.org posts in March had noticed that you
were working on something, so I let things rest.

But this git-bug thing will take a while to get established. That makes
me wonder if we independent of that should do what was partly discussed
in this thread:

Change the front page text of bugzilla now to at least make people
better aware that it might be a bad place to file bug (which even some
kernel developers are not aware of).

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

If you ask me, that's the wrong way around. We IMHO want an LLM that
helps users to submit good reports directly. That is in the interest of
users, as then they won't waste time on submitting something that an LLM
later will reject quickly, which they'll rightfully find annoying. And I
guess it will be less work and thus cheaper for LLM, too.

The LLM, for example, could, at the start of the process, query (or ask)
"uname -r" and ask "Is it a bug with a graphics driver for AMD or Intel"
-- and depending on the outcome tell users, "You are at the wrong place,
you have a heavily patched and outdated kernel, your want to file that
at your distro" or "You are in the wrong place, you have to file that at
gitlab.freedesktop.org/drm/".

In fact I started looking into something like that two days ago (by
taking a closer look at Chris's review prompts and how sashiko uses them
-- and how something like that can be used for a LLM assisted bug
reporting process. But I need a few days to see if I get this to work well.

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

Just wondering: what Richard posted in this thread (would you be willing
to host that?), or do you have something else in mind?

> -- though I expect final human-based
>   review will be required for this to be not waste people's time
Yeah, but that is always the case at some point -- whatever we do will
likely improve things for developers and users.

> [...]
> - 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

There will be a email on lore in the latter case, too? Sounds like it,
but I just want to be sure. Because it's already painful to search for
existing bugs, as one has to search lore, bugzilla, and in some cases
places like gitlab.freedesktop.org/drm/,
https://github.com/thesofproject/linux/issues,
https://github.com/AsahiLinux/linux/issues,
https://github.com/Rust-for-Linux/linux/issues,
https://github.com/multipath-tcp/mptcp_net-next/issues,
https://github.com/facebook/zstd/issues, etc. Would be good to lower
that number; in a ideal world we'd likely have a "bugs" mailing list
where all of those external issue tracker automatically forward all
newly submitted issues and later replies to.

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

All that sounds like I can continue with regzbot (which we soon
hopefully will rework to make it more useful for everyone) without
stepping on each others toes and solving the same or similar problems
twice? Because that would be a pity and a waste or rare ressources,
which I guess we'd all like to avoid.

But regzbot afaics (and definitively correct me if I'm wrong) handles
just a subset of bugs -- but does that in all the places (email, gitlab,
github), which git-bug won't be able to handle afaics.  I see some
overlap with bugspray (which seems to be still involved, am I right?),
but I guess we might find a way to work together there.

Ciao, Thorsten