Re: slowly decommission bugzilla?

Sasha Levin <[email protected]> Sun, 1 Mar 2026 11:16:04 -0500
Newsgroups dev.linux.lists.ksummit
Message-ID <aaRmRGzJutgAruJt@laps>
On Sun, Mar 01, 2026 at 11:01:07AM -0500, James Bottomley wrote:
>On Sun, 2026-03-01 at 10:23 -0500, Sasha Levin wrote:
>[...]
>> As an example, this bug report came in today with no replies:
>>
>>   
>> https://lore.kernel.org/all/[email protected]/
>>
>> I fed it to an LLM. It decoded the stack trace (as described above),
>> then traced the crash to iptfs_reassem_cont() at xfrm_iptfs.c:905:
>> skb_put() on a non-linear skb. It identified the offending commit
>> (5f2b6a9095743), the code author (Christian Hopps), the relevant
>> maintainers, and a couple more vulnerable call sites in the same
>> function. Not perfect, but enough to get the report to the right
>> people with useful context already attached.
>
>Lore says there's been no follow up to that email ... shouldn't someone
>check with the reporter that the fix actually works?

Hmm? I don't think that there's a fix available yet.

>> What I'd like to propose: set up something like [email protected] with a
>> bot that watches it. When a report comes in, it:
>
>If we're going to link an agent to a mailing list, why not simply have
>it scan all of them?  Something like the way the old ksymoops used to.

We could. In my mind a mail to bug@ would just be a marker for the bot to run
on. Do we have a better way to identify bug reports?

I don't want to send every single incoming mail through the LLM to determine if
it's a bug report or not. That would make it slightly expensive :)

>>   1. Pulls the oops/stack trace from the email (if exists)
>>   2. Figures out the kernel version, obtains or builds debuginfo, and
>>      decodes the stack trace
>>   3. Reads the relevant source, identifies root cause, offending
>> commit,
>>      and the right maintainers/lists
>>   4. Forwards the report with its analysis to the right list, Cc'ing
>>      the right people
>>
>> One email address, no tooling required from the reporter, bugs get to
>> the right list with a decoded stack trace and first-pass analysis.
>> The analysis will be wrong sometimes, but even just the decoded trace
>> and correct routing is better than what bugzilla gives us today.
>
>If an agent is going to be doing this, then the agent could reply with
>the results and add the emails it deduced should be notified.  You can
>add caveat phrases like "Hi I'm an automatic reply from a LLM and I
>think ..."

Yup! In this example, it would reply with the processed report (the one I
linked in the previous mail), but also cc the list of folks it identified in
the "Contacts" section.

>It also looks quite easy for the agent to identify whether this is a
>regression or not and flag that more clearly (and possibly follow up as
>well, which means we get regression tracking back).

Agree

-- 
Thanks,
Sasha