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