Andrew Morton on Kernel Hacking

Susie Denmark writes "Linux Format has a brief interview with Andrew Morton, the maintainer of the Linux kernel 2.6 tree. Andrew discusses the debates behind revision control systems (the BitKeeper and CVS), new kernel features and his own -mm tree. Will the issue of using RCSes in the kernel tree ever die down? Does it really matter?"

Comments

Gittish

[minginqunt]

> Will the issue of using RCSes in the kernel tree ever die down?

Um, yes. It did so three months ago. It's called git.

Re:He may be maintaining the 2.6 tree...

[slavemowgli]

Actually... he's not even maintaining 2.6. He's maintaining -mm, which is kind of like the development branch where patches get tested before being merged into mainline, but the vanilla 2.6 tree is maintained by Linus, and it doesn't look like that's going to change anytime soon.

rcs.

[s4m7]

Will the issue of using RCSes in the kernel tree ever die down?

It more or less has since they've replaced bitkeeper with git.

Does it really matter?

Well, it probably doesn't matter to you if you arent part of the tree-maintenance heirarchy, since individual developers don't need to use git directly to submit their patches, but the maintainers use them to keep track of who submitted what patches when, when they were merged, if they were tweaked etc. Many maintainers were uncomfortable with BitKeeper because it was a proprietary platform meaning that they could go out of buiness, revoke linus's liscence, or any number of other things could go wrong. That's exactly what happened and so git was created to replace it.

using some kind of RCS/SCM solution is absolutely critical in a project as large as the linux kernel, if for no reason other than to have a history of where stuff came from. If they'd been using something from the get-go it would be a lot harder for SCO to make the claims that they have.

Re:rcs.

[iabervon]

Actually, git has a number of nice features for individual developers and even testers. There's a great thing called "bisect" for finding what broke the system. You tell it "this version worked, and that version didn't." Then it checks out for you another version to try. You build it, test it, and tell it if it works. Then it checks out another one for you. After O(log(n)) steps, it tells you which patch broke things. It's actually faster than trying to figure out which patch it was by thinking about the problem.

The reason this sort of thing is possible is that git is a free system, and people can write the tools they need to interact with it. It's true that most people didn't have to use BK, but git is useful in many more situations and there aren't the licensing reasons not to use it, so you're likely to see people tell you to use git just to move data around.

For that matter, git has extensions to the patch format, so you need to use it if you want to make certain types of patches in ways that are easy to review (such as a patch that renames a file; standard diff requires the reviewer to figure out what is different between the lines removed from the old name and the lines added to the new one).

Re:He may be maintaining the 2.6 tree...

[Shazow]

Actually... he is maintaining the primary 2.6 tree, as well as his own -mm tree. At least as as I can tell from his bio and this ancient slashdot article:

"Linus Torvalds has released his final 2.6.0-test kernel, calling it the 'Beaver In Detox'. Following this release, Linus says that 2.6 development will be led by Andrew Morton."

More sources:

Gentoo Kernel Doc:

"Linux 2.6 is maintained by Andrew Morton, who works closely with Linus Torvalds to deliver a fast, powerful, and feature-packed Linux kernel. Development is happening at incredible pace and this kernel tree is now very mature."

And, of course, THE GOOGLE QUERY (of doom).

At the least, they're both maintaining it. Or something...

- shazow