Re: MPTCP tree in linux-next

[Matthieu Baerts <matttbe@kernel.org>]

Hi Mark,

Thank you for your reply!

On 19/12/2025 15:30, Mark Brown wrote:
> 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.

Thank you, that makes sense!

>> 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.

Ah yes, I forgot about pending-fixes. It is easy to create such branch
containing only fixes.

>> 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.

Typically, the Net maintainers send a PR to Linus once a week, with the
content of 'net'. Once merged, 'net' points to Linus' merge commit, and
'net-next' is then merged with 'net'.

(Before each merge window, 'net' is merged with 'net-next'.)

When we have new features depending on new fixes, the fixes are sent
first to be included in 'net'. Then we wait for 'net-next' to get those
fixes (max 1 week), and we send the new features to be included in
'net-next'.

If 'linux-next' already contains a merge between 'net' and 'net-next',
maybe it is fine to merge a branch also containing this merge? But I
guess that's possibly not recommended if conflicts are solved differently.

> Do other net subtrees have workflows for this, I'd
> imagine they run into similar issues?

Good point. I don't see any special case for that. I see that some repos
have 'for-next' branches like 'wireless' and 'wireless-next', but it
looks like it is not the good time to look because for the moment
'net-next' is closed.

Perhaps it is enough to work in a "best-effort" way and to provide a
"pending-fixes" branch with only fixes on top of 'net', and "for-next"
with patches that applies on top of "net-next". Conflicted patches are
skipped until the next 'net' / 'net-next' sync.

>> - 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.

Ah yes, I see. We could adapt when the automated sync is done, but
that's probably not enough.

>> 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.

Indeed, it might be better to do that. I will check later to put that in
place. I guess we mainly have to change the way patches are sent.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.