"Quite frankly, at least for me personally, what I would rather have [...] is a less rigid maintainership structure," Linus Torvalds proposed. He went on to explain, "let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem." He noted that git is an excellent tool for spreading out maintenance, then added, "but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries." Linus continued:

"I've personally always been against _strict_ maintainer lines, so I've always taken stuff 'past' the maintainer anyway (and sometimes maintainers have complained, because they feel like they 'own' their subsystem, and I either tell them to stuff it, or say 'my bad', depending on whether they had a valid _technical_ complaint or not)."

"Despite my heart-felt feelings that we should support different people in trying out different things, one of the issues is also that I'm obviously not myself a security person. I can 'decree' all I want, but in the end, I really want the people *involved* to merge security stuff," Linus Torvalds explained during the ongoing discussions surrounding the Linux Security Modules code. He added, "there's the 'core LSM hooks' on one side, but there's also the 'what modules make any sense at all to merge?' on the other, and I really don't have the expertise to make any sensible judgments except for the pure 'process' judgment that we should not hardcode things to just one module!" Linus pointed out that Chris Wright is currently listed as the only LSM maintainer, but hopefully others would step up to help:

"Quite frankly, I do not want to take it over. I really really really hope that people that are interested in security can work this thing out, and my only requirement is that it doesn't end up being any kind of force-feeding of opinions and ideas, since clearly there is tons of room for disagreement in the area.."

Following Andrew Morton's recent comment, "this just isn't working any more," Miles Lane asked, "what can be done to reduce the huge number of build fixes required to release an MM tree?" Andrew jokingly replied, "my mind turns to cattle prods." Regarding the suggestion that he could publicly list the offenders he quipped, "I could name names, but it would look like 'grep @ MAINTAINERS' ;))" He continued to say, "I don't think much can be done about it, really," going on to explain:

"See, what I do is to merge probably hundreds of patches into the -mm-only part of the tree and then, after a few days, get down and compile-test it all, then fix it, then runtime test it all, then fix that. Because it is vastly more efficient to do all this work against hundreds of patches than it is to do it against one patch at a time, no?

"And guess what? All the other maintainers do the same thing: someone sends you a patch, it looks good, so you commit it. After you've committed a decent batch of patches, get in there and test it all. Problem is, I often will get in there and do all that testing before the subsystem-tree owner has done his testing."

Marcelo Tosatti became the maintainer of the 2.4 stable kernel when he was 18 years old in November of 2001. His first kernel release was 2.4.16 on November 26'th which very quickly followed the earlier 2.4.15 to address an issue with filesystem corruption. Two years later, he has recently released 2.4.23 and plans to soon put the 2.4 stable kernel into maintenance mode, only addressing bugs and security issues.

Living in Brazil, Marcelo currently works for Cyclades Corporation. In this interview he looks at how he became the 2.4 maintainer, the challenges involved, and brings us up to date with the current status of the 2.4 kernel.