Re: slowly decommission bugzilla?

On Sun, 2026-03-01 at 16:35 +0100, Laurent Pinchart wrote:
> On Sun, Mar 01, 2026 at 10:23:00AM -0500, Sasha Levin wrote:
> > On Sat, Feb 28, 2026 at 03:56:11PM -0500, Steven Rostedt wrote:
> > > On Sat, 28 Feb 2026 21:28:57 +0100 (CET)
> > > Richard Weinberger <[email protected]> wrote:
> > > 
> > > > Wouldn't that only work if the report is able to upload the
> > > > kernel debug info too?
> > > 
> > > Yes, this would be nice if we had the help from the distros that
> > > could automate this process.
> > 
> > So I've been poking at using LLMs for this.
> > 
> > decode_stacktrace.sh is great when you have a debug build handy,
> > but asking a random bug reporter to obtain debuginfo, set up the
> > tooling, and run the script is quite the hurdle.
> > 
> > The debuginfo problem is solvable on the server side though. Given
> > a kernel version string from the oops, an LLM can figure out which
> > distro and package version the reporter is running, pull the right
> > debuginfo (or build from the matching config/tag if no debuginfo
> > package exists), and run decode_stacktrace.sh itself.
> 
> Do we really have to use non-deterministic tools that will inevitably
> produce correct-looking but otherwise useless backtraces from time to
> time, confusing developers and wasting time for everybody, when we
> can instead easily develop tools that will work in a deterministic
> fashion ?

So "non-deterministic" is the new anti-AI phrase?  I get that some
people think it's never useful, but this does seem like one of the
cases where humans can't be bothered most of the time and AI can
provide a reasonable response.

We could even give it bonus points for building the kernel with the
revert and asking the reporter to try it (which should also be possible
if a bit expensive in terms of cloud resources).

> I'm getting *really* sick of people pushing for LLM usage when it's
> clearly the wrong tool. Please stop.
> > 
That's both uncalled for and unfair.  If we're not going to let AI
write code then the most useful thing it can do for us is automate
repetitive task we can't be bothered to do most of the time.  Bug
triage seems to me to be an excellent example of that, particularly
with reporters who aren't on upstream kernels.  Rather than having it
declared useless ab initio, let's give it a chance to see how useful
the actual results are.

Regards,

James

> 
>