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