Re: [GIT PULL] Networking deletions for 7.1

[Pratyush Yadav <pratyush@kernel.org>]

On Fri, Apr 24 2026, Roman Gushchin wrote:

> 2c on Sashiko:
>
> 1) I'm working on an infrastructure to separate pre-existing issues from
> new issues. My current thinking is to stop reporting these issues with
> reviews of new patches and instead put them into some database and give
> maintainers access to it. Sashiko will automatically deduplicate issues
> and index them by the source file/subsystem. Hopefully it will mean that
> maintainers will see only a limited number of issues in source files
> they support. But I have yet to see how it works in practice.
>
> But I'm somewhat concerned that this way many of these issues will
> remain there forever and by reporting them with new material we actually
> have better chances to get them fixes. Maybe it should be configurable
> per-subsystem. I'm very open for ideas here.

Yep, I agree. When I am looking at a series, the context is fresh in my
mind and if there are small fixes I can write them and send quickly. I
would be less likely to wade through a database, since it is a lot
harder to build the mental context. But then I work with subsystems that
get far fewer patches than something like networking so the noise isn't
that much of a problem for me.

Maybe you can visually separate the pre-exsiting issues (perhaps also
allow filtering?) so people can quickly see the problems with the patch
and don't always have to parse the rest?

>
> 2) Re false positives vs finding more bugs I had the same experience.
> It's easy to tweak it to be more conservative or creative, but it comes
> at a price. It seems like the real answer is simple a better model. We
> saw a big improvement internally switching from Gemini Pro 3.0 to 3.1.
>
> Thanks

-- 
Regards,
Pratyush Yadav