Re: slowly decommission bugzilla?

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Sun, 01 Mar 2026 11:15:53 -0500
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> 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 <richard@nod.at> 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).

Sounds an interesting idea, but making AI write patches (or produce
an output that requires a more strict format) is not something that
doesn't work out of the box, if you use only LLM. 

I did some tests myself, writing a program meant to strings on a .po 
file, meant to complete a language translation(*). The only way it worked
is when I used a prompt asking it to produce a "from/to" table, and
then writing a function that would do the string replacements.

If we want AI to produce revert patches, it is probably better to:

- use a prompt for LLM to pick the original code and generate a new
  code to replace;
- compile the code to be sure that LLM didn't break it. If it does,
  send back the issues to LLM - eventually repeating this step a
  couple of times before giving up;
- run "diff" command line (or use a diff library) to produce a valid
  output.
    
(*) In the end, I opted to not use it in practice, nor the produced
    patches, as despite LLM translation were not bad (I tested it on
    languages I can understand), it didn't pick right some more
    technical messages. It also mangled a little bit with message
    capitalization and whitespacing. 

    If I had enough time to do translations myself, though, I would
    use it, as the core of the translations are good, but a
    significantly amount of them would require manual adjustments. 
    Still, it could reduce a lot the time spent on doing 
    translations.

Thanks,
Mauro