Re: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support

[David Hildenbrand (Arm)]

> 
>> and have people
>> base work against that?
> 
> This I'm not so sure how it would work. Assuming we have submaintainers with
> their trees and branches, the final "stable branch" is merged from those.
> But it's not a good base for work targeting the same merge window, as that
> work would likely go to one of those submaintainer trees. But then it can't
> be based on the result of merge of all submaintainer trees. That could only
> work for patches targetting the next cycle (after the stable branch becomes
> part of rc1).
> 
> So either patches can be based on rc1 and applied as topic branches in a
> submaintainer tree and then merged, or if they really depend on something
> already in a submaintainer tree, then based on the respective topic branch
> that's part of it.

Right, most patches can be sent against the "stable branch", but cherry-picked
on a submaintainers branch / topic tree.


> 
>> This would be 'source of truth' and what we eventually send to Linus.
> 
> Yes.
> 
>> In that world, the maintainers perform conflict resolution, but with git rerere
>> we need only do this once.
> 
> I think the conflicts would arise from merging the submaintainers' branches
> to the mm-next tree, and if they get updated and the merges are recreated
> (like linux-next works) git rerere avoids resolving the same conflicts again.
> 
> Hm like Andrew said, this needs a diagram indeed :)

It's one of the first things we'll discuss in the upcoming meetings ... I want
to talk to some other folks (in particular, TIP and KVM) to understand how they
are handling that.

Hopefully I'll find some time after my inbox calmed down a bit ... jeez, 1500
mails in one week if my eyes didn't betray me.

-- 
Cheers,

David