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