<div dir="ltr">Hello,<br><br>I am not a kernel developer but I think I can answer this.<br><br>This is how I understand it:<br><br>Short version:<br><br>-next is a very special Linux branch managed by Linus Torvalds<br>that contains changes from all subsystem that are considered<br>good candidate for the next release, but people want to see some<br>more testing or &quot;maturation&quot;.<br><br>-mm is one of the many Linux subsysitems (Memory Management).<br><br>Less short version:<br><br>The -next tree is a branch of Linux managed by Linus Torvalds containing<br>&quot;experimental&quot; or &quot;not mature enough&quot; changes.  When Linus is convinced<br>that a change is good, it will &quot;graduate&quot; it by merging that change into a<br>Linux release candidate (-rc).  The time a change sit in -next before<br>graduating to -rc is variable and depends on the change itself; something<br>obviusly correct will graduate fast, while some other change might need a<br>long -next time or could even never graduate. The act of deciding what<br>graduates and what doesn&#39;t take place in a point in time known as the<br>&quot;merge window&quot;. Better said, a given version of -rc has a well specified<br>deadline for things to get into it; if a change doesn&#39;t graduate fast<br>enough, it slips into the next window.<br><br>So, after this illustration, you might thing of the possibility of some<br>changes rotting in -next forever. Can you imagine after decades of kernel<br>life what sort of mess this &quot;limbo&quot; branch could become? That&#39;s why<br>periodically -next is &quot;nuked&quot; and rebuilt from all changes not yet<br>graduated yet but are still worth of keeping around. That&#39;s the occasion to<br>do some cleanup. This process of burning and rebuilding -next is mostly<br>automated; one useful tool is &quot;git rerere&quot; [0][1] which let you record<br>conflict fixes you did in past merges.<br><br>This workflow is sometimes called &quot;-next branch workflow&quot; and is explained<br>in the gitworkflows(7) man page [2]. I made a few pictures to explain it<br>graphically in a post[3] of my blog.<br><br>linux-mm, in the other hand, is a branch that contains all Memory<br>Management (MM) related changes, as you can see in the MAINTAINERS file[4].<br><br>So, about the message you linked: &quot;Most of the -mm tree is already in the<br>linux-next tree&quot; means that at that point in time, October 2013, -next<br>included most of -mm. But the message doesn&#39;t say two &quot;obvious&quot; but<br>important things:<br><br>1) the other inclusion is not true! -next wasn&#39;t equal to -mm, but surely<br>   much larger (think of all changes awaiting graduation from the other<br>   subsystems)<br>2) given the dynamic nature of -next, which is periodically destroyed and<br>   rebuilt, that statement only held only until the following -next rebuild<br>   (i.e. the beginning of the new development cycle).<br><br>Please take what I say with a grain of salt, as I never participated to the<br>kernel development and I am only an external observer. Consider what I<br>write here as an explaination attempt, and I invite all people who know<br>better to correct it.<br><br>Cheers,<br>Giovanni<br><br>[0] <a href="https://git-scm.com/docs/git-rerere">https://git-scm.com/docs/git-rerere</a><br>[1] <a href="https://git-scm.com/blog/2010/03/08/rerere.html">https://git-scm.com/blog/2010/03/08/rerere.html</a><br>[2] <a href="https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html">https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html</a><br>[3] <a href="http://www.gghh.name/dibtp/2014/07/25/the-next-branch-workflow-and-criss-cross-merges.html">http://www.gghh.name/dibtp/2014/07/25/the-next-branch-workflow-and-criss-cross-merges.html</a><br>[4] <a href="https://github.com/torvalds/linux/blob/master/MAINTAINERS#L6955">https://github.com/torvalds/linux/blob/master/MAINTAINERS#L6955</a><br></div>