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).

Multiplatform VCS

[should_be_linear]

If you like Git but you want to use multiple platforms try Mercurial: http://www.selenic.com/mercurial/wiki/index.cgi Performance is excellent, it is written in Python. So far version 0.7, but projects is very active.

Re:Multiplatform VCS

[boa13]

I frequently look at both projects, and it seems to me that Git is more active and has a bigger base (users and developers). These past ten weeks or so, Mercurial seems to have slowed down, while Git has accelerated towards 1.0. Besides, Git performance has improved a lot in the past few months, and disk usage has gone way down, the comparisons you can find on the web are now meaningless and outdated. Also, Git has been ported to Cygwin, and works on most Unices.

However, Mercurial offers a better user experience, is easier to get into, is truly-cross-platform, and so might be a better choice for smaller projects. On the long term, I would place my bet on Git, though.

Re:Multiplatform VCS

[MenTaLguY]

Mercurial might be farther along if Larry McVoy hadn't (about ten weeks ago, curiously enough) gotten rid of one of their core developers by threatening their employer.

BitKeeper is pure dag-nasty evil.

Re:You What!!

[Carewolf]

You have version control in the fact that versions are realeased every now and then, you can just diff them manually.

The lack of version control tool, does not mean the lack of version control. It is just done manually. While slower manual control is infinitely more flexible than computer assisted version control, which was why Linus waited until he found a tool that didn't hinder him too much.

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