Kernel space: Interview with Andrew Morton

I have sensed that there is a bit of confusion about the difference between -mm and linux-next. How would you describe the purpose of these two trees? Which one should interested people be testing?

Well, things are in flux at present.

The -mm tree used to consist of the following:

• 80-odd subsystem maintainer trees (git and quilt), eg: scsi, usb, net.
• various patches which I picked up which should be in a subsystem maintainer's tree, but which for one of various reasons didn't get merged there. I spend a lot of time acting as backup for leaky maintainers.
• patches which are mastered in the -mm tree. These are now organised as subsystems too, and I count about 100 such subsystems which are mastered in -mm. eg: fbdev, signals, uml, procfs. And memory management.
• more speculative things which aren't intended for mainline in the short-term, such as new filesystems (eg reiser4).
• debugging patches which I never intend to go upstream.

The 80-odd subsystem trees in fact account for 85 per cent of the changes which go into Linux. Pretty much all of the remaining 15 per cent are the only-in-mm patches.

Right now (at 2.6.26-rc4 in "kernel time"), the 80-odd subsystem trees are in linux-next. I now merge linux-next into -mm rather than the 80-odd separate trees.

As mentioned previously, I plan to move more of -mm into linux-next - the 100-odd little subsystem trees.

Once that has happened, there isn't really much left in -mm. Just

• the patches which subsystem maintainers leaked. I send these to the subsystem maintainers.
• the speculative not-for-next-release features
• the not-to-be-merged debugging patches.