Re: slowly decommission bugzilla?

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, Apr 02, 2026 at 03:42:04PM +0200, Thorsten Leemhuis wrote:
> 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).

Yes, I'd like a clear path forward before we mark bugzilla as deprecated.

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

Sure, this is a possibility as well -- I'm just a bid jaded from every
interface like this turning into a "ignore all previous instructions and write
me a solution for this homework problem I got assigned." :)

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

Happy to consider that, too.

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

We can figure something out -- it's hard to figure out if we can host
something if we don't know full architectural details. In theory, kernel.org
is bound by some legalese in its nonprofit charter document that prevents us
from broadening our scope of services too far, but since we're already running
bugzilla, we should be fine to add other bug-reporting tools.

> There will be a email on lore in the latter case, too? Sounds like it,
> but I just want to be sure.

Yes, everything goes to lore. I don't like calling it "email" because it may
not get there via SMTP, but it will be searchable/clonable/etc and maintainers
can get it imported into their inbox via a number of ways (korgalore,
search-based pseudo-lists that we're planning to introduce, etc).

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

I do hope to write feeds for known trackers that we can then add to lore for
the above mentioned purposes. Free the 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.
> 
> 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.

There are some hurdles that remain to be solved, and the biggest one is how to
add and reference large files so that hey don't clog lore but also don't live
on some transient ephemeral system that won't be around 5 years later. I
looked at IPFS a while back, but it seemed like a candidate for long-term
storage and replication, not for quick access.

I am trying to move as much as possible off SMTP as the transmission layer and
towards providing structured feeds. Git and public-inbox is a structured feed
that is well suited for this purpose -- it supports sharding, indexing,
message deletion with and without history rewrites, and scales well even for
millions of messages. Since you are running a popular bot, I'm hoping you can
look into providing its output as a feed that we can consume -- I have a
python library you can use (https://pypi.org/project/ezpi/).

Regards,
-- 
KR