Re: MPTCP tree in linux-next

[Matthieu Baerts <matttbe@kernel.org>]

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.