Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Oct 04, 2022 at 11:03:48AM -0700, Linus Torvalds wrote:
> And while the MAINTAINER file is useful for a fiel mapping, I'm not
> convinced it's all that useful for the "product/component category"
> mapping, because I doubt people will actually fill that in well (and
> reliably) enough.

Sure, but for a best-effort first go at it, it may do more good than harm. If
someone says "this is not mine, sorry, try X", the triage team will select the
suggested component instead and retrigger the bot with a new set of
addressees.

> With actual bisection data, it's fairly easy (get the emails from the
> commit that got bisected). But things like "use the backtrace in the
> oops to figure out who to add to participants" is likely a bit more of
> a "use clever heuristics" kind of thing.
> 
> Anyway, I do think that some kind of automation would be really good,
> at least for reports that have bisection information or backtraces in
> them. Without automation, people _will_ be overwhelmed on the first
> level response to bug reports (ie the "try to figure out who to bring
> in" front).
> 
> But if the automation is too stupid, people will start ignoring the
> report emails just on the assumption that it got thihngs wrong.

Well, then at worst we'll have gone a full circle, since that's the situation
right now anyway.

> Of course, if the automation is really solid enough, I think it should
> work on lore.kernel.org, not on just a bugzilla thing.

It would be cool if we could use all those big AI projects at LF to help out
here. The trouble is that there's not really anything to train it on, because
there is no reliable mapping from message threads to subsystem components.

Maybe as the triage team goes along, it can start feeding correctly triaged
bugs to a PyTorch instance. :)

-K