[Update] mm-next status 2026/08/27

["David Hildenbrand (Arm)" <david@kernel.org>]

Hi,

this is the second status update about the MM transition [1]. Since the last
update [2] we had two further mm-next calls.

Below a status update on things that happened, things that were decided, or
things that were discussed.

I'm sure I forgot something or messed something up; all involved people are on
BCC, so please correct me!


1) Tree/branch Locations
------------------------

The mm-next tree is now live at:

	https://git.kernel.org/pub/scm/linux/kernel/git/mm/linux.git/

And the memblock tree now has a mirror at:

	https://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock.git/


2) mm/linux.git ("mm-next") Branches
------------------------------------

The following branches are now updated daily (well, mostly ;) ) and linux-next
started integrating mm-next instead of slab/memblock/Andrew's MM trees yesterday
the first time. Successfully as it seems.

for-next-fixes:
- Based on Linus' master outside the merge window and on the last tagged
  release during the merge window
- Integrates all component's “for-next-fixes” branches and Andrew's mm-
  hotfixes-unstable branch.
- Goes to linux-next.git pending-fixes.

for-next:
- Based on for-next-fixes.
- Further integrates all component's “for-next” branches and Andrew's mm-
  unstable branch.
- Goes to linux-next.git master.

for-test:
- Based on for-next.
- Further integrates all all component's “for-test” branches and Andrew's mm-
  new branch. For now it's really only mm-new.

All integration trees are entirely rebuild daily, similar to linux-next, to then
get force-pushed. Commit IDs will be stable as long as they remain stable in the
source branch from which they are getting merged into mm-next. Branches are
tagged daily.

After integration and before pushing the branches, the I currently perform
various cross-compiles for the for-next-fixes and for-next branch + performs a
local CI run. More tests to be added in the future.

The for-test branch is best-effort for now (effectively only includes mm-new).


3) Component Branch Handling Rules
----------------------------------

We started creating a list of rules component trees should obey, and reached out
to other trees to learn best-practices.

For example:

- During the merge window, for-next + for-test should be mostly frozen, but for-
  next-fixes remains active.
- Before the merge window starts, for-next should only contain material
  targeting the next release.
- No new features into for-next around -rc5/-rc6. There are certainly
  exceptions.
- Fixes should ideally be in for-next-fixes for at least a week.
- Otherwise we target 2 weeks of stable commit IDs in next before PULL.

More to come as we move forward and learn.


4) Against Which Branches to Submit Patches
-------------------------------------------

We decided on the following preference list (highest to lowest):

(1) Submit against component for-next tree (indicated in MAINTAINERS)

(2) Submit against mm-next integration tree

(3) Support against Linus' master / release / rc

For many patches it won't matter, and many submitters will get it wrong either
way. We can always ask for a resend on conflicts.

Especially when a series involves multiple components, we'll have to learn about
best practices.

Ideally, we pick up stuff into for-next when it was properly reviewed and no
major changes are expected (which matches linux-next rules :) ). If a resend is
required after already in for-next, we can ask to submit against the old base,
or yank the series to then ask for a resend against the updated branch.

We discussed where to place cover letter information in a git-focused model.
Likely, merge commits already provided by tools like b4 shazam will be the best
and easiest option.


5) PULL Request Handling
------------------------

We decided to follow a staged approach:

Stage 1: we keep the existing model whereby slab/memblock/Andrew send PULL
requests independently.

Stage 2: I will start queuing patches for some components and start getting
experience with simpler PULL requests, before moving on to the next stage.

Stage 3: switch to the KVM model: as we get more components and more conflicts,
maintainers will send PULL requests to the mm-next maintainer, which will send
(bundled) PULL requests to Linus, performing similar integration testing as done
during mm-next maintenance.

Instead of involving Andrew into stage 3, we will instead try taking more and
more MM components over, so we can avoid him changing his workflow.


6) Documentation
----------------

We discussed what to document and where to document.

We'll likely create a "mm" subdirectory in Documentation/process/ where we will
document things like:
- Tree/branches, integration flow, CI ... essentially a lot of stuff included in
  these status update mails
- Submitter guidelines, including templates for bug reports / bug fixes / cover
  letters
- MM preferences, such as selftests primarily in C, coding style, AI review
  expectations, when to send new revisions, how to send new revisions ...

We'll also need MM component maintainer doc. We'll either make them publicly
available in the process docs as well, or maintain them out of tree.

We also discussed whether some easy way to (semi-automatically) send information
to first-time submitters would be helpful. Apparently, there is similar work
going on on the lkml level.


7) AI Review
------------

We discussed current challenges with Sashiko, including unclear expectations for
submitters when it comes to reports about existing problems, and how the
external website is suboptimal, but flooding the mailing list is also bad.

This topic should be discussed with the wider MM community in the future, and
maybe better tooling can help us.


8) Patchwork Integration
------------------------

We discussed how the existing MM patchwork instance [3] might make it easier for
us to keep track of the state of upstream submissions.

b4 has a great patchwork integration that we can use as well.

Mike already taught the MM CI to reflect CI status in patchwork; maybe other
status (AI review?) could similarly be reflected there to have one central tool.

We also talked about other approaches, such as netdevs patch review queue [4]
and patchew [5].


9) Next Steps
-------------

- Relocate slab tree.
- Better integration tests.
- Start picking patches for smaller, well-isolated components and see how that
  integrates.
- David to send first PULL request for this stuff.


10) Topics to Discuss Next
---------------------------

What we'll cover in the next session(s) will likely be around:

- Hotfixes process
- MM component separation: how to reduce or prepare for conflicts.
- MM component maintainer communication: how to efficiently communicate


There are still plenty of things to figure out. If you feel like you should be
part of the discussions and were missed so far, please let me known and I can
add you to the meeting invitation.


[1]
https://lore.kernel.org/linux-mm/3166fcdd-5f08-4f7c-a743-192d0e0207d1@kernel.org/
[2] https://lore.kernel.org/r/bed81e01-7303-4957-bd7d-38e3a094e96f@kernel.org
[3] https://patchwork.kernel.org/project/linux-mm/list/
[4] http://netdev.bots.linux.dev/suie.html
[5] https://patchew.org/linux/