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
It's bound to be said, so why not by an AC?
FreeBSD core/committers is an excellent model,
indicative of the relative maturity/experience
of the individuals involved.
No egotistical "I must approve everything".
It's been done and the idea *failed*. CVS cannot solve the problem at hand.
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).
Of course CVS does not solve the problem of quality control, but it doesn't make that claim. It is interesting to me that people seem to be conflating the issue of giving people write access to the CVS Repository with having a CVS Repository in the first place. It is ridiculous to assume that if you have a CVS Repository, then you are going to allow a lot of people to just check in whatever they want. Come on, this is a problem that has been basically solved by every other software project of any significant size. It is not rocket science, it is not even a theoretically difficult issue. Or stated better: ``How many projects have not already solved this issue?'' I think that the resounding answer is that Linux is the only major Open Source project that does not use source code control of some variety and it is rather an embarrassment to software engineering in general that best practices are not in evidence in Linux. People replying to this post are not only conflating the existence of a CVS repository with allowing anyone to write anything to it, but they are also ignoring the other benefits of source code control. For example, if I upgrade to the next version of Linux and I discover a new bug, I can use CVS to help me track down the changes to the source which might have caused the bug. This is an invaluble aid in debugging which I would be severely hampered at work if I did not have. And, no I do not have the luxury of writing all the code myself, so I cannot `just know' where the problems were introduced. Another advantage that CVS gives you is `cvs blame', aka `cvs annotate' so that you can discover who made the offending changes. This is a very powerful social motivator to people with write access to ensure that their changes are in fact up to the quality standards of the group that they are in. And don't forget the advantage of being able to get a snapshot of the current state of the system, without having to wait for another blessed version to be released from the Cathedral. I find that this is invaluble when doing development for work, since I can easily keep my code in sync with the work of other developers because they use a tool that was designed with exactly this in mind: CVS. And lastly, don't forget that a decent source code control system is a necessary pre-requisite to setting up a decent nightly build/regression suite. And, I don't think that I have to stress the value of that. I think that the interesting question to ask is what is the phenomenon that causes us to slavishly follow Linus and his anti-engineering biases that violate the best practices of the industry, rather than just forking off Finux and using source code control. We could even add a kernel debugger while we were at 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?
Arrghh! I've seen this too many times on Slashdot. "He has a loose * tooth; he may lose * it soon." * Definitions courtesy of dictionary.com.
Badgeez?! We don' need no steenking badgeez!
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