Re: slowly decommission bugzilla?

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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

We would still accept bug reports generated without that tool, and
document what we expect from a properly formatted bug report, right ?

> 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

-- 
Regards,

Laurent Pinchart