MPTCP tree in linux-next

[Matthieu Baerts <matttbe@kernel.org>]

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.