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