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

[Sasha Levin <sashal@kernel.org>]

On Thu, Sep 11, 2025 at 09:13:28PM +0200, Nicolas Frattaroli wrote:
>On Thursday, 11 September 2025 17:05:23 Central European Summer Time Sasha Levin wrote:
>> On Thu, Sep 11, 2025 at 04:48:03PM +0200, Nicolas Frattaroli wrote:
>> >On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Levin wrote:
>> >it doesn't seem like Assisted-by is the right terminology here, as
>> >the code itself makes me believe it was written wholesale by your
>> >preferred LLM with minimal oversight, and then posted to the list.
>> >
>> >A non-exhaustive code review inline, as it quickly became clear
>> >this wasn't worth further time invested in reviewing.
>>
>> Thanks for the review!
>>
>> Indeed, Python isn't my language of choice: this script was a difficult (for
>> me) attempt at translating an equivalent bash based script that I already had
>> into python so it could fit into b4.
>
>There's something to be said about these tools' habit of empowering
>people to think they can judge the output adequately, but I don't
>want to detract from the other point I'll try to make in this reply.
>
>> My intent was for this to start a discussion about this approach rather than
>> actually be merged into b4.
>
>I know that, and you did get feedback on this approach already from
>others, specifically that it did not solve the core issue that is
>poorly utilised metadata and instead applies hammer to vaguely nail
>shaped thing.
>
>And your reaction was to call them personally biased against this
>approach, and to loudly announce you would ignore any further
>e-mails from them.
>
>Now while I won't claim Laurent Pinchart isn't one of the louder
>critics of your recent LLM evangelism, I can't really see a fault
>in his reasoning: your insistence on finding an LLM solution to
>every and any problem is papering over the real pain point,
>which is that Link: should contain useful information, so that
>you can click on the link and get the information and not have
>to do a search (LLM assisted or not) for said information.
>
>So the responses you expect to this patch should seemingly meet the
>following two criteria:
>1. we're not supposed to critique the implementation, as it's an RFC
>   and therefore should not get comments on anything but the general
>   approach,
>2. we're not supposed to critique the general approach, because saying
>   that this solution is neither reliable nor efficient is a result
>   of personal bias against the underlying technology.
>
>I don't condone the arguments based on energy usage because any use
>of electricity in a grid that's not decarbonised will be open to
>value judgements. For example, my personal non-workplace-endorsed
>opinion is that electricity used on growing zucchini is wasted,
>as they are low-nutrient snot pumpkins masquerading as cucumbers.
>
>My main criticism on the approach end of things, if I am allowed
>an opinion, is that this does not make Link: tags more meaningful,
>nor does it solve the problem of automated tools adding sometimes
>useless noise to something humans are supposed to be reading (which,
>some may point out, your tool makes even worse.)
>
>While bisecting, I often come across things where I'd love to be
>able to immediately see what discussion preceded the problematic
>patch with just one click and pageload between. Shoveling GPUs
>into Sam Altman's gaping cheeks does not allow me to do that,
>or at least not any better than a search on lore with dfn: would
>already allow me to do.

I very much agree with your general observation:

1. I don't think that this script solves the underlying Link: issue.

2. It papers over the real problem

3. I don't think that today's LLMs can solve any fundamental issue we're facing
in kernel-land.

4. I am really happy (as Laurent said) to apply my big hammer to anything that
looks like a nail.


We've started[1] the workflows@ list (which is how I stumbled on this thread)
about 5-6 years ago when the concern from multiple maintainers was that we all
have our magical scripts, they are seriously ugly, and everyone are ashamed of
sharing them. So this list was an effort to get the ball rolling on folks
sharing some of those ugly workflows and scripts in an attempt to standardize
and improve our processes.

I've shared this very hacky b4-dig script as exactly that: I have a very ugly
bash script that addresses some of the issues Linus brought up around being
able to find more context for a given patch/mail.  I use that script often, it
helps me spend less time on browsing lore (no, dfn: won't find you syzbot
reports or CI failures), and it just "works for me".

I'd love if we end up with a great solution for Link:, I'm not asking anyone to
stop working on that, nor am I claiming that this is a good long-term solution
for the problem. All this is is a utility script that fits my needs *TODAY*.

So no, I wasn't looking for criticism on workflows@ (this isn't even on lkml,
ksummit-discuss, or anything like that).  I was looking to share a workflow
that I have and see if folks have any ideas, suggestions, or would potentially
want to do something like this on their own.  I wasn't looking for an almost
religious "vim vs. emacs"-esque choire of "LLMS SUCK" or comments about Sam
Altman's rear end.

Maybe this is why folks are reluctant to share their ugly scripts?



[1] https://lwn.net/Articles/799134/ - "The session closed with the creation of
a new "workflows" mailing list on vger.kernel.org where developers can discuss
how they work and share their scripts".

-- 
Thanks,
Sasha