On Wed, Sep 10, 2025 at 06:55:55AM -0400, Sasha Levin wrote: > On Wed, Sep 10, 2025 at 01:13:42PM +0300, Laurent Pinchart wrote: > > 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. > > Really? Elsewhere in this thread I've already pointed out that something like > this is very helpful because having to review hundreds of commits for > backport/CVE assignment using our current scheme of Link: just pointing to the > original submission and not any discussions is a major pain and a time waste.
That's debatable at best, I've stopped counting the number of developers who are unhappy with the over-aggressive backport policy, and how LLMs pick commits for backport that have no reason to be backported. Don't get me wrong, I wouldn't want to be responsible for maintaining stable kernels given the volume of commits. It's a never-ending, thankless job. Still, claiming that LLMs solve the problem doesn't seem true to me, they merely provide some sort of automation to allow us to claim the problem has been addressed. It's closer to theatre than engineering. > Both Linus and Greg echoed the same concern. Heck, this thread started because > Linus complained about how much of a human time waste our current scheme is. > > So when presented with a real problem and a tool that can help mitigate it, > you're still choosing to attack because it's LLM based and you have something > personal against that. I've long had something personal about using the wrong tool for a job :-) That has very little chance of changing. > Sorry, I'm done with this argument. Use it if you like, don't use it if you > don't. -- Regards, Laurent Pinchart
