The chain of subsystem trees guides the flow of patches into the kernel, but it also raises an interesting question: what if somebody wants to look at all of the patches which are being prepared for the next merge window? Developers will be interested in what other changes are pending to see whether there are any conflicts to worry about; a patch which changes a core kernel function prototype, for example, will conflict with any other patches which use the older form of that function. Reviewers and testers want access to the changes in their integrated form before all of those changes land in the mainline kernel. One could pull changes from all of the interesting subsystem trees, but that would be a big and error-prone job.
The answer comes in the form of staging trees, where subsystem trees are collected for testing and review. The oldest of these trees, maintained by Andrew Morton, is called „-mm“ (for memory management, which is how it got started). The -mm tree integrates patches from a long list of subsystem trees; it also has some patches aimed at helping with debugging.
Beyond that, -mm contains a significant collection of patches which have been selected by Andrew directly. These patches may have been posted on a mailing list, or they may apply to a part of the kernel for which there is no designated subsystem tree. As a result, -mm operates as a sort of subsystem tree of last resort; if there is no other obvious path for a patch into the mainline, it is likely to end up in -mm. Miscellaneous patches which accumulate in -mm will eventually either be forwarded on to an appropriate subsystem tree or be sent directly to Linus. In a typical development cycle, approximately 10% of the patches going into the mainline get there via -mm.
The current -mm patch can always be found from the front page of
http://kernel.org/
Those who want to see the current state of -mm can get the „-mm of the moment“ tree, found at:
http://www.ozlabs.org/~akpm/mmotm/mmotm-readme.txt
Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile.
The other staging tree, started more recently, is linux-next, maintained by Stephen Rothwell. The linux-next tree is, by design, a snapshot of what the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing lists when they are assembled; they can be downloaded from:
http://www.kernel.org/pub/linux/kernel/people/sfr/
How the linux-next tree will fit into the development process is still changing. As of this writing, the first full development cycle involving linux-next (2.6.26) is coming to an end; thus far, it has proved to be a valuable resource for finding and fixing integration problems before the beginning of the merge window. See http://lwn.net/Articles/287155/ for more information on how linux-next has worked to set up the 2.6.27 merge window.
Some developers have begun to suggest that linux-next should be used as the target for future development as well. The linux-next tree does tend to be far ahead of the mainline and is more representative of the tree into which any new work will be merged. The downside to this idea is that the volatility of linux-next tends to make it a difficult development target. See http://lwn.net/Articles/289013/ for more information on this topic, and stay tuned; much is still in flux where linux-next is involved