* 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