Welcome!

Linux Authors: Adrian Bridgwater, Bob Gourley, Elizabeth White, Pat Romanski, Gary Kaiser

Related Topics: Linux

Linux: Article

Linus tries to make himself scale

Some kernel developers ask how Linus Torvalds can continue as its lead developer

(LinuxWorld) -- A long and sometimes bitter thread entitled "A Modest Proposal: We need a Patch Penguin" has been the center of attention for many on the Linux kernel mailing list the past few weeks. (See Resources for the URL to join the list, but beware before subscribing, it has very high traffic.) Underlying the debates on the best methods and/or tools to improve the kernel hacking process is a more troubling question: can Linus Torvalds continue to successfully lead Linux development?

Rob Landley began the 300+ message thread on January 28th, when he wrote:

Okay everybody, this is getting rediculous (sic). Patches FROM MAINTAINERS are getting dropped on the floor on a regular basis. This is burning out maintainers and is increasing the number of different kernel trees (not yet a major fork, but a lot of cracks and fragmentation are showing under the stress). Linus needs an integration lieutenant, and he needs one NOW.

The problem to Landley's eyes was that "Linus doesn't scale, and his current way of coping is to silently drop the vast majority of patches submitted to him onto the floor." Because of this, Landley argued, the 2.4 kernel very nearly forked, maintainers were burning out, and needed fixes were not getting into the kernel. His proposed solution is to have a single person act as Linus's patch tracker to make sure things don't get lost.

Torvalds responded to Landley's post by explaining reasons why some patches get "dropped" (not included in the tree). He also offered his opinion on what is really needed to improve the scalability of the kernel hacking process. He rejects the idea that changes aimed at getting him to accept more patches from more people is a good thing. Torvalds feels that it is the various kernel "maintainers" who need help, not him. At issue is the question of how patches should flow.

Torvalds wrote:

I've got about ten-twenty people I really trust, and quite frankly, the way people work is hardcoded in our DNA. Nobody "really trusts" hundreds of people. The way to make these things scale out more is to increase the network of trust not by trying to push it on me, but by making it more of a _network_, not a star-topology around me.

The heart of the controversy seems to stem from an extended period last year following the release of 2.4. Until recently, there was no new development tree and instead of passing maintenance control of the 2.4 kernel over to Alan Cox, as he usually does after a new release, Torvalds continued to work with the 2.4 release. Odd numbered kernel versions, as in 2.1, 2.3, and now 2.5, are development trees that are not for public consumption.

It was during this period that Torvalds made a strong, swift move to try to put an end to a series of problems 2.4 was having with VM (virtual memory). He yanked out Rik van Riel's VM code and replaced it with all new VM code contributed by Andrea Arcangeli. Cox and others were unhappy with Torvalds abrupt change to a production release. Fear of a real fork, not just separate trees, with some developers following Torvalds and some Cox, began to surface. That fear became more palpable when Cox decided not to continue as the head maintainer for the 2.4 stable tree. Marcelo Tosatti picked up that mantle of responsibility last November.

More Stories By Joe Barr

Joe Barr is a freelance journalist covering Linux, open source and network security. His 'Version Control' column has been a regular feature of Linux.SYS-CON.com since its inception. As far as we know, he is the only living journalist whose works have appeared both in phrack, the legendary underground zine, and IBM Personal Systems Magazine.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.