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

[Vlastimil Babka (SUSE)]

On 5/26/26 10:33, Lorenzo Stoakes wrote:
> [trimmed cc list to avoid noise, apologies if I excluded anybody who is
> interested in this!]
> 
> On Fri, May 22, 2026 at 11:13:42PM +0200, David Hildenbrand (Arm) wrote:
>> On 5/22/26 18:11, Nico Pache wrote:
>> > On Fri, May 22, 2026 at 9:13 AM Vlastimil Babka (SUSE)
>> > <vbabka@xxxxxxxxxx> wrote:
>> >>
>> >> On 5/22/26 17:07, Nico Pache wrote:
>> >>>
>> >>> Whoops I manually changed the coverletter subject to reflect that this
>> >>> in on mm-hotfixes-unstable but never updated the others...
>> >>
>> >> But why? That branch is for hotfixes that would go to the current 7.1-rcX
>> >> series. mm-unstable would be the correct one for this, AFAICT.
>> >
>> > Sorry this was a misunderstanding. The goal here was to base this off
>> > the closest base commit behind where my v17 already lies in the tree.
>>
>> Ah, I guess this is a problem of "v17 is already in mm-unstable, so against what
>> to base v18".
>>
>> Yeah, we touched on that problem in the LSF/MM process discussion ...
> 
> I may be misremembering but... :) [correct me if wrong]:
> 
> Wasn't the general conclusion that we maintain a stable branch (Linus's tree +
> stuff that's been reviewed and is locked in for next release),

This I think basically yes.

> 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.

> 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 :)

> We'd have mm-new which would contain everything for testing.
> 
> SO my question is - would we even need an mm-unstable in that world?
> 
> What role would it perform? Surely we'd want the stable branch going to
> linux-next, so it's not that, it's not quite initial testing either as
> mm-new would perform that duty.
> 
> It would potentially make life a bit easier for somebody doing a new series
> to avoid merge conflicts, but that could then make life harder because
> there'd be an implicit dependency of their series on what's-in-mm-unstable?
> 
> If everything's based on the stable branch, things are surely clearer?
> 
> Curious what people think here.
> 
> (I also wonder if we could have branches for versions of series so we could
> do some kind of an easy diff between versions but maybe that'd create too
> much noise :)
> 
>>
>> --
>> Cheers,
>>
>> David
> 
> Thanks, Lorenzo