Slashdot Mirror
Linus Does Not Scale
EmilEifrem writes: "Seems like everybody's getting more and more frustrated by Linus' (in-) ability to handle patches. Rob Landley just wrote an "RFC on Penguin Patch Management" wherein he proposes a "Penguin Patch Lieutenant" system that he believes would scale better. The full discussion can be found on the Linux kernel mailing list. Linus seems to dislike it, as usual, source code maintenance tools/organization are for wimps!, but a lot of others find it a good idea. Anyway, it's a very good read."
To make a long story short; Because Linus doesn't want one. It has been proposed many, many times, but Linus has always shot it down. Logistically, it would be a bear anyway.
Before everyone flames Linus for his dislike of CVS and other management tools ....
From Kernel Trap:
His general point is summarized with this statement, "One 'patch penguin' scales no better than I do. In fact, I will claim that most of them scale a whole lot worse". He goes on to explain this statement quite thoroughly, adding: " In short: don't try to come up with a 'patch penguin'. Instead try to help existing maintainers, or maybe help grow new ones. THAT is the way to scalability".
Say what you want about Linus' attitude - Having a kernel lieutenant probably wouldn't help either. Either way, there's only so much one person can do.
Note that things like CVS do not help the fundamental problem at all. They allow automatic acceptance of patches, and positively _encourage_ people to "dump" their patches on other people, and not act as real maintainers.
We've seen this several times in Linux - David (Miller), for example, used to maintain his CVS tree, and he ended up being rather frustrated about having to then maintain it all and clean up the bad parts because I didn't want to apply them (and he didn't really want me to) and he couldn't make people clean up themselves because "once it was in, it was in".
I know that source control advocates say that using source control makes it easy to revert bad stuff, but that's simply not TRUE. It's not easy to revert bad stuff. The only way to handle bad stuff is to make people responsible for their own sh*t, and have them maintain it themselves.
"The good die first." "Most of us are morally ambiguous, which explains our random dying patterns." --- MST3K
For example, there was a bug in the ne2000 driver that Alan Cox points out here. According to Mr. Cox, "this is one tiny example of maybe thousands of other similar flaws lurking. There is no obvious automated way to find them either."
As "president" of FreeBSD. Then he had the courage to step down and become a "normal" member of the "core-group", a collective in which every member has the main responsability for a part of the FreeBSD code. Apart from the core group there are other committers but the core group decides who these are and can revoke commit-rights in cases of abuse.
This is a nice distributed system that continues to work very well when the load gets higher; also noone is indispensible, noone has to be afraid what would happen to FreeBSD if a certain person would somehow drop out.
Of course Linus has every right in the world to remain the status quo, even if it damages Linux. After all Linux is his baby and he can do with it what he likes. Whether it is a good idea to rely on an OS with this kind of a leadership structure is another matter however. But noone can force Linus to change, since he doesn't force anyone to use Linux (take it or leave it).
Microsoft must be laughing
Well, I can't claim any insider knowledge, but I bet that all kind of crap goes on within the MS development teams that we never hear about.
When you've got a lot of bright people working hard on a very big, complex thing, something would be very wrong if you didn't get these kind of problems arising occasionally.
Personally, I think Linus is right, and all those people who are bitching should sit down and think for a moment, and perhaps think of ways they can help to make Linus's very hard task a little easier, rather than just complaining.
It's been attempted multiple times, and what was found out was that CVS makes things even more chaotic as more people gradually gain commit, as a consequence, all of the CVS kernel forks died.
The real solution, as Linus has pointed out, is that everyone has a small group of trusted people who they take patches from for a given subsystem. What you end up with is Linus at the top with his 10 or so trusted people below him each responsible for submitting patches for large subsections of the kernel, and those guys accept patches from other maintainers who again are in charge of yet smaller subsections within the previous. This type of tree can handle very complex projects and scale very well provided everything is designed modularly with -good interfaces- (another point that Linus has been trying to drive home). So what Linus wants to see happen is that people -stop sending him patches directly- and start sending them to subsection maintainers.
Now the good news. You couldn't tell it by this Slashdot post but everything I have just said has already been happening. People are moving over to the new system and things are getting worked out, the reason you still see posts like this is that some people just haven't quite worked their way into the new system yet. So yes, it's a problem and it's one that is already being solved, no need to panic.
To quote Linus: "If you can't get a patch through to me find someone else you can go through."
That statement alone will go a long way towards making the reorganization happen.
Sigs are awesome huh?
Repeat after me: the business community doesn't run Linus kernels anyway. They run RedHat kernels, or Mandrake kernels, or maybe Debian kernels. The distributor is completely welcome to adopt these patches if they see the benefit of them and have time to assure themselves of their benefit. The state of the Linus kernel really has very little to do with what an enterprise user of Linux will experience.
Now, it will look kinda bad for Linus if we end up with a system where patches are tested out in shipped distributions before they are tested in the main kernel tree, but that's a PR problem more than anything.
Your right to not believe: Americans United for Separation of Church and
Did ANYBODY on /. actually read the ML Thread on this problem the kernelpeople have?
/.ers should read the actual thread before they post every instant and absurd mindfart that comes to them. Be it about jelousy amongst kernelhackers or Linus supposedly bossing around or whatever other sorts of utter bullshit.
Rob Landley and Linux Torwalds aren't bashing their heads in on one another nor is ANYBODY of the Kernel Team about to 'dethrone' Linus. Whatever that may be.
In fact Landley suggest a "Patch Penguin' to actually EMPOWER Linus in his actuall job as an arcitect of Linux.
Linus in turn says that officially shifting patchin jobs to somebody else (the said Patch Penguin) won't save the problem of, for instance, people being to lazy to clean up their code dependencies.
Linus wants to see a sort of 'web of maintainers' where everyone knows and works with a overseeable amount of others (just like he does) rather than a big patcheritis boiling around a main single/pair/group of developers.
It may, IMHO of a absolute non-kernel savy guy, kinda boil down to the monolitic/modular kernel discussion that comes up every know and then.
Then again, on the other hand I gather the impression that Rob Langley and Linus Torwals aren't that far apart in seeing the issue that needs to be addresses rather than seeing different ways of aproaching a solution to it.
Anyhow,
We suffer more in our imagination than in reality. - Seneca