Re: Some clarifications on the upstreaming process

[Steffen Klassert <steffen.klassert@secunet.com>]

Hi Matthieu,

On Wed, Sep 09, 2026 at 12:22:14PM +0200, Matthieu Baerts wrote:
> Hi Steffen, Paolo,
> 
> (+cc Pablo, Florian)
> 
> Sorry to jump in the discussion, but I have similar issues with MPTCP
> patches.
> 
> On 09/09/2026 11:23, Paolo Abeni wrote:
> > On 9/9/26 8:38 AM, Steffen Klassert wrote:
> 
> (...)
> 
> >> 4) Some patches for the ipsec and ipsec-next tree don't get Sashiko
> >> reviews either because they don't apply to net or net-next, or
> >> because of some other reasons I'm not aware of.
> 
> >From what I saw, sashiko.dev tries to apply patches on top of the
> correct tree by at least looking at the modified files and the
> MAINTAINERS file, and possibly the prefix [1] from what I understood.

Yes, that's correct. I did not notice this yet. Thanks!

> 
> For example this recent patch [2] got applied on top of 96f01b53c2d0,
> which corresponds to today's 'ipset' tree [3] (tag: ipsec-2026-09-07)
> 
> [1] https://github.com/sashiko-dev/sashiko/issues/48
> [2]
> https://sashiko.dev/#/patchset/migrate-state-fixes-v2-0-c3e2767f0d96%40secunet.com
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git
> 
> For Clashiko, it only tests what's for net/net-next, same as for the
> selftests, etc. if I'm not mistaken.
> 
> >> This is the biggest
> >> issue, I see the Sashiko review only after I sent a pull request.
> >> This makes the upstreaming process complicated and delays fixes
> >> quite a bit. I requested some infrastructure from the LF to get
> >> this fixed, but no answer so far. Any other ideas how to fix
> >> this issue?
> > 
> > I think are 2 separate points:
> > 
> > 4.1 missing sashiko reviews on edge cases
> > 4.2 difficulty to reproduce the sashiko/clashiko review process in advance.
> > 
> > WRT 4.1 things should generally improve over time, with the exception of
> > patch that do not apply. I think we can't do much for them, but they
> > also should not matter much, right?
> > 
> > WRT 4.2 the current guidance is to run AI reviews before submission.
> > Sashiko could be installed and run locally. The nipa instance (clashiko)
> > is slighly more effective than sashiko.dev because it runs several
> > recent models and its result are indeed hard to replicate locally/in
> > advance.
> > 
> > Clashiko currently runs on (very significant) meta-sponsored budget, I
> > think it would be hard to extend it's usage to netdev's subsystems.
> 
> We might need to find a solution for the subsystems for this 4th point.
> I have the same issue with MPTCP, and it seems it is the same with
> Netfilter (and likely others) from what I saw. I would prefer to have
> Clashiko reviews before applying patches on my side: to reduce the risk
> to deal with new issues later on, and to let the author dealing with
> that (instead of me days/weeks after).

Right, patches must get the review before they get applied to
a git tree, not after. It was always like that and we should
try to get back to it. The current workflow feels broken from
a submaintainers point of view. The submaintaners are now the
bottleneck.

> >From what I understood, Clashiko is still being tweaked, and that's the
> current priority. Maybe later, subsystems can have their patches
> reviewed by Clashiko as well?

That's what I would hope for.

> If that's a budget issue that cannot be solved easily, I wonder if
> Clashiko shouldn't ignore subsystems patches: I see its value, but I
> also see the cost for the different subsystems :-/

Maybe we can work with a compromise in the meantime. Clashiko
reviews all subsystem patches that apply to net or net-next
when the patches are submitted to the list as it is now.
But then the subsystem pull requests are done without
resending all patches to the list. So patches do not get
reviewed again with the pull request. That would avoid the
hassle with reviews of already applied patches.

Would that approach be acceptable for the netdev maintainers?