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

[Lorenzo Stoakes <ljs@kernel.org>]

[sorry busy with many things so took a while to get back to this]

On Tue, May 26, 2026 at 10:42:51PM +0200, Vlastimil Babka (SUSE) wrote:
> 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@kernel.org> 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.

I think it's _vital_ to have this one source of truth, and for that to be what
goes to linux-next, then eventually Linus.

I think sending stuff that's still unstable to linux-next, while it gets early
testing, is more problematic than helpful overall.

And us improving testing in mm-new can mean we get some meaningful testing
involved (AI review bots helping also).

(Also Linus said linux-next doesn't get tested all that much anyway :P)

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

I feel like it could get hairy pretty quick, but I guess the key thing here is -
maintainers resolve merge conflicts.

As long as we have a specific _solid_ basis for work.

I think actually this speaks to it being sensible for each submaintainer with a
separate tree to maintain their own repos rather than branches.

We need to determine what this baseline would be for each tree though.

So perhaps each submaintainer tree has for-mm-next that's the stable branch from
mm-next + any stabliised local changes.

And each week this gets merged to mm-next, and everybody resets to mm-next
stable branch?

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

OK so topic branches = series people have submitted?

I did wonder if we could somehow maintain the separate versions too so we could
diff between them easily also...

And yeah it makes sense, if your series TRULY has a dependency on another, to
base that on the topic branch.

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

Yes they could arise there, and if we use the model mentioned above with each
submaintainer tree having its own for-mm-next branch, then when that gets reset
to mm-next it could cause conflicts for topic branches etc.

But then that would not be a repeatable resolution I suppose.

But would updates really be a thing though in general? If it's for-mm-next
[submaintainer tree] -> mm-stable [mm-next] each time, then there cannot be
further updates as those are the finalised commits right?

>
> Hm like Andrew said, this needs a diagram indeed :)

Yes, am happy to draw/document something when we finalise things.

Cheers, Lorenzo