Re: [RFC] b4 dig: Add AI-powered email relationship discovery command

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Sep 09, 2025 at 02:54:53PM -0400, Sasha Levin wrote:
> On Tue, Sep 09, 2025 at 11:26:19AM -0600, Jens Axboe wrote:
> > On 9/9/25 11:22 AM, Laurent Pinchart wrote:
> >> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> >>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> >>> emails for a given message ID. This helps developers find all relevant
> >>> context around patches including previous versions, bug reports, reviews,
> >>> and related discussions.
> >>
> >> That really sounds like "if all you have is a hammer, everything looks
> >> like a nail". The community has been working for multiple years to
> >> improve discovery of relationships between patches and commits, with
> >> great tools such are lore, lei and b4, and usage of commit IDs, patch
> >> IDs and message IDs to link everything together. Those provide exact
> >> results in a deterministic way, and consume a fraction of power of what
> >> this patch would do. It would be very sad if this would be the direction
> >> we decide to take.
> >
> > Fully agree, this kind of lazy "oh just waste billions of cycles and
> > punt to some AI" bs is just kind of giving up on proper infrastructure
> > to support maintainers and developers.
> 
> This feels like a false choice: why force a pick between b4-dig-like tooling
> and improving our infra? They can work together. As tagging and workflows
> improve, those gains will flow into the tools anyway.
> 
> It's like saying we should skip -rc releases because they mean we've given up
> on bug free code.

I really have trouble thinking this is a honest argument. We're
discussing the topic in the context of a project where we reject
thousands of patches all the time when they don't go in the right
direction.

Throwing an LLM at the problem is not just a major waste of power, it
also hurts as it will shift the focus away from improving the
deterministic tools we've been working on. Using an LLM here only
benefits the companies that make money from those proprietary tools.

> Perfect is the enemy of the good. You're arguing against a tool that works now,
> just because it's not ideal, and to chase perfection instead. I'd rather be
> "lazy" and skip the endless lore hunts.

Nobody will stop you from being lazy or anything else. I'll however push
back against the bad influence on others.

-- 
Regards,

Laurent Pinchart