* MPTCP tree in linux-next
@ 2025-12-19 12:35 Matthieu Baerts
2025-12-19 14:30 ` Mark Brown
0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Baerts @ 2025-12-19 12:35 UTC (permalink / raw)
To: Mark Brown, Stephen Rothwell; +Cc: MPTCP Linux, linux-next, Mat Martineau
Hi Mark, Stephen,
First, thank you, Stephen, for all the work you did around linux-next,
and Mark for taking over!
I'm currently maintaining MPTCP with Mat, and I wonder if that would be
OK to add the MPTCP tree in linux-next. We never asked before, mainly
because we handle our tree [1] with TopGit on top of both 'net' and
'net-next' trees, but technically, I'm sure we can find a way to have
branches that would suit linux-next.
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?
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.
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)?
Two important notes:
- A synchronisation with 'net' and 'net-next' is done by our CI once a
day, except during the weekend or in case of conflicts.
- Our patches are currently sent as "patches", not in a pull request, so
patches will be applied with a different SHA.
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.
One last thing: no hurry here, especially at this period of the year!
[1] https://github.com/multipath-tcp/mptcp_net-next
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MPTCP tree in linux-next
2025-12-19 12:35 MPTCP tree in linux-next Matthieu Baerts
@ 2025-12-19 14:30 ` Mark Brown
2025-12-19 15:31 ` Matthieu Baerts
0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2025-12-19 14:30 UTC (permalink / raw)
To: Matthieu Baerts; +Cc: Stephen Rothwell, MPTCP Linux, linux-next, Mat Martineau
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MPTCP tree in linux-next
2025-12-19 14:30 ` Mark Brown
@ 2025-12-19 15:31 ` Matthieu Baerts
2025-12-19 15:49 ` Mark Brown
0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Baerts @ 2025-12-19 15:31 UTC (permalink / raw)
To: Mark Brown; +Cc: Stephen Rothwell, MPTCP Linux, linux-next, Mat Martineau
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MPTCP tree in linux-next
2025-12-19 15:31 ` Matthieu Baerts
@ 2025-12-19 15:49 ` Mark Brown
2025-12-19 15:51 ` Matthieu Baerts
0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2025-12-19 15:49 UTC (permalink / raw)
To: Matthieu Baerts; +Cc: Stephen Rothwell, MPTCP Linux, linux-next, Mat Martineau
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
On Fri, Dec 19, 2025 at 04:31:25PM +0100, Matthieu Baerts wrote:
> On 19/12/2025 15:30, Mark Brown wrote:
> > On Fri, Dec 19, 2025 at 01:35:51PM +0100, Matthieu Baerts wrote:
> 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.
Yeah, if the resolution is the same it's not an issue - it's if they
diverge somehow that there's a concern.
> 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.
You could always start with that and figure out the complicated stuff
later.
> > 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.
Sounds good.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MPTCP tree in linux-next
2025-12-19 15:49 ` Mark Brown
@ 2025-12-19 15:51 ` Matthieu Baerts
0 siblings, 0 replies; 5+ messages in thread
From: Matthieu Baerts @ 2025-12-19 15:51 UTC (permalink / raw)
To: Mark Brown; +Cc: Stephen Rothwell, MPTCP Linux, linux-next, Mat Martineau
On 19/12/2025 16:49, Mark Brown wrote:
> On Fri, Dec 19, 2025 at 04:31:25PM +0100, Matthieu Baerts wrote:
>> On 19/12/2025 15:30, Mark Brown wrote:
>>> On Fri, Dec 19, 2025 at 01:35:51PM +0100, Matthieu Baerts wrote:
>
>> 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.
>
> Yeah, if the resolution is the same it's not an issue - it's if they
> diverge somehow that there's a concern.
>
>> 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.
>
> You could always start with that and figure out the complicated stuff
> later.
Indeed, I will do that!
>>> 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.
>
> Sounds good.
Thank you, I will contact you later when this new workflow is in place!
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-19 15:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-19 12:35 MPTCP tree in linux-next Matthieu Baerts
2025-12-19 14:30 ` Mark Brown
2025-12-19 15:31 ` Matthieu Baerts
2025-12-19 15:49 ` Mark Brown
2025-12-19 15:51 ` Matthieu Baerts
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox