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

He may be maintaining the 2.6 tree...

[brilinux]

But what does he know about 2.7!!??

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.

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

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.

Wow

[gowen]

I'm suprised he finds the time, given the heavy load of muck raking biographies that he manages to write.

Re:Wow

[TubeSteak]

You should take tips from him on time management.
your personal homepage is dead. http://www.ma.man.ac.uk/~gowen/

Yet Andrew manages to hold down a day job while researching and writing dozens of books about British celebrities.

Less time posting on /. and browsing Amazon please.

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

Great professionalism!

[joib]

So, uh, it seems that AM is a professional level headed guy. No surprises there really.

But to my gripe: Starting the interview with "Do you think it was good to have had the time with BitKeeper in kernel development, or should they have stuck with CVS?". Gee, being so in tune with what's happening in kernel land just makes want to run to the nearest newsstand and get the latest "Linux Format": "The essential read for all Linux users".

You What!!

[ObsessiveMathsFreak]

Oh. My. Gods. From TFA

AM: Well, we never even used CVS. Before BitKeeper we basically weren't using anything - just a bunch of patches sitting on Linus' hard drive and it uploaded occasionally. We had no tracking of what had gone in the kernel at all.

Someone, please tell me this is a dream. Wake me from this nightmare. Dear gods!! There was no version control on the Linux Kernel!? How? What? When? Where? Why? WTF!!?

I am not rightly able to comprehend the kind of confusion of ideas that would provoke such a situation.

Stinking font

[po8]

The Linux Format folks really need to change the default font for their webpages, which appears to be Tahoma. I just spent two minutes of my life trying to figure out what a "dustering filesystem" is. Found a Googlewhack, anyhow.