Subject: Re: MPTCP tree in linux-next

From: Mark Brown <[email-masked]>
Date: Fri, 19 Dec 2025 14:30:35 +0000

On Fri, Dec 19, 2025 at 01:35:51PM +0100, Matthieu Baerts wrote:

> Currently, we "export" commits from the TopGit tree in two branches:
> 'export' and 'export-net':

> - 'export-net' is on top of 'net', but it also contains patches that are
> useful for our CI: fixes from other trees, temp workarounds, instruction
> files for the CI, extra debugging, etc.

> - 'export' is on top of 'net-next' and 'export-net', so with the extra
> commits for the CI.

> For linux-next, I guess we should remove these extra commits for the CI,
> right?

Right, we only want changes that are intended to go to Linus.

> Would it be OK to add one new branch containing both the fixes (for
> 'net') and the new features (for 'net-next') on top of 'net-next'?
> Sometimes, we have new features that depend on fixes that are not in
> 'net' yet. Having one branch should help here.

One branch is certainly OK, though it is desirable to have fixes
separately since as well as the main -next branch we also build
pending-fixes which includes only fixes, the goal being to validate that
there's no unintended dependencies on non-fix changes.  That's not
essential though.

> With one branch on top of 'net-next', we might still have issues if some
> of our fixes for 'net' cannot be applied on top of 'net-next'. A
> solution would be to have our branch on top of 'net' and containing:

> - MPTCP fixes
> - a merge commit with 'net-next'
> - MPTCP features

> Would that also work for you? Or do you prefer having only the MPTCP
> commits on top of 'net-next'? Or two branches, one on top of 'net' and
> one on top of 'net-next' (without the patches that depends on the ones
> in 'net', not in 'net-next' yet)?

We generally don't want that merge unless it'd get sent to Linus
eventually so your second option feels like a better choice here for my
money (Stephen might have a better idea here though?).  I don't know how
promptly net-next gets the fixes merged up, or how often dependencies on
fixes is an issue.  Do other net subtrees have workflows for this, I'd
imagine they run into similar issues?

> - Our patches are currently sent as "patches", not in a pull request, so
> patches will be applied with a different SHA.

The main issue with that would be that it would create work with the
duplicate commit detection and reporting we do which would get annoying
for all concerned.  I suspect the actual merges would mostly end up
fine, git tends to figure this stuff out fairly well.

> We can certainly easily change both points if that would help you: when
> the sync is done, and send PR instead of patches. I guess we could have
> situations where when 'linux-next' is rebuilt, a patch would appear in
> both Networking and MPTCP trees, which can confuse Git. Maybe changing
> our workflow can help to prevent such issues.

If you were to switch to sending a PR of the actual commits in -next
that'd make life easier but that'd need you to work out the workflow
with whoever you're sending the patches to.  I guess you could adopt a
hybrid flow where you use TopGit with regeneration until you send the PR
and then freeze the patches included in the PR?  You could use the PR as
a base for new stuff while it's in flight.  There are trees that are
managed in a patch queues that use a workflow a bit like that.