On Sun, Jan 20, 2002 at 08:33:33AM +0200, Shlomi Fish wrote: > > I disagree with your claims. And by raising the flag of mutiny I do not > intend to demand them. I intend to implement a system that will make them > a reality. > > This is a productive mutiny, in which people do something instead of just > whine, attack, or spread FUD.
I know you disagree with our clainms. Again: why would your suggestion not lead to a reduction in kernel coherence and quality as we described? > Like I said, I believe it's impossible for Linus to pass his decision for > each and every patch that goes in. OK - whether the VM should be replaced > - should be ultimately his decision. However, if there's a patch to the > VM, then the VM maintainer or its architect should be able to apply it > without consulting LT. Alright. Right now it is Linus who is the maintainer of the VM. Can you suggest someone who would do the job better? > As of now, from what Moshe Bar said, there were many patches, which fix > important bugs, and were rejected by Linus, since only he has an ultimate > repsonsibility on what goes into linux-2.[45].x-vanilla. Moshe said that > the S.u.s.e kernel had 200 patches to apply. By definition (according to > the Joel test which I referenced) the kernel should be at any point > bug-free. This is why using a CVS and delegating responsibility for > applying patches is a must. I don't think you completely understand the nature of VM debugging. More often than not, it's not a straightforward business like "Oops, NULL pointer dereference -- I forgot to initialize", where it's very clear both where the bug is and what the fix does. VM debugging can, perhaps, more often be described as "tuning". No VM can behave perfectly, or even well, in all circumenstances, so the simplistic goal of "bug free" does not apply. Instead, the VM hackers try to have the system general enough and yet respond well to all reasonable cases. That's very hard to do because you can't really know in advance which tuning directions truely solve the problems and which only appear to do so due to the by-definition limited range of behavior models that the developer's initial testing covered. That was exactly the problem with Rik's original 2.4.0 VM -- it appeared to be perfect, but the larger user base introduced by the even version number uncovered serious problems with it. So you can't really separate the global policy making with taking in VM patches when it comes to VM tuning. Thinking, in advance, which VM patches would improve the system in the long run and which would not require such qualities as complete understanding of the entire system, complete understanding of the usage patterns by userspace code and by users, consulting the contradicting suggested ways to solve the problem, ability to weigh the existing arguments and testing results for and against a patch, and, of course, a great deal of intuition. I doubt that in the last months before he passed the kernel on to Marcelo Linus did much for the kernel other than just this. Now, you can say his judgement was mistaken in some choices, perhaps he should have been more aggressive in accepting patches or less aggressive at other times. But if Linus didn't do this job, someone else would still have to. You can't evade that. > > > to see that I'm not the only person who thinks so. And give me another > > > example for a project with the scope and number of developers of the Linux > > > kernel that does not use a source control system. > > > > Give me another example for an open source operating system that > > captured a significant market share. > > > > Give me another example for a successful major operating system in > > the market that is not controlled by a single vendor. > > > > Give me another example of successful operating system developed in > > the last 10 years that uses monolothic kernels. > > > > Give me another example of a successful operating system that does > > not include any management utilities or libraries. > > > > These are all non-sequitors. I don't see how they are derived from the > original request for an example. They intend to show that the existence or the lack of an example of other projects working similarly to Linux has no relevancy to the issue at hand, unless one is willing to consider every uniqueness of Linux a weakness. > My article referenced the Joel Test, which Joel Spolsky claims is a better > alternative than SEMA. I don't know if the Joel Test is about top-down or > bottom-up software. In fact, I think it applies to software in general. It can't be used with the bottom-up development model as it requires writing code according to a specification and a schedule. > My model can be used whether for bottom-up or top-down software > development. No, it cannot. Your model assumes that the role of the top developer is to direct the project (since that is his only way to control it), while in a bottom-up approach the top developer /selects/ a direction from among the many suggsted by independent factions, and which make their suggestions in the form of source code. > I'm not saying Linus should not lead the Linux kernel development and be > the ultimate authority on what goes into Linux-vanilla and what stays out. > Despite the fact that I don't like many of his decisions (especially the > kdb one) I think we are better off with him remaining in this role. > However, one man, especially a family man like LT, cannot humanly commit > all the patches by himself. Perhaps you have the wrong mental image of what Linus does. Please correct me if I am wrong. It appears to me that you think most of his significant work is to read the code, talk to people, and think what should be done, or possibly code some of the changes himself. In fact, he does none of those things, at least according to what can be seen on list and what he says publicly. Although it does happen from time to time that Linus makes pronouncements and everybody follows (e.g., kdev_t), this is the exception rather than the rule. Mostly Linus sits with his mailer (I suspect Pine), reading patches, and saying to himself "Like it" [copies mail to his "to-apply" folder] or "Don't like it" [presses D]. He has a very clear idea of what the source code is and sometimes where he wants it to go, but the way for him to judge an actual change is by source code, and the way for him to approve or disapprove is to accept or not accept the patch. So if you take that away from Linus, he won't actually be doing much at all. > Like I said earlier, I don't have a problem with Linus being ultimately > responsible for what goes in or stays out of the kernel. Someone has to do > this, and it may just as well be him, and if anybody does not like his > decisions - fork or _maintain his own branch at the source control > repository_. Maintaining a kernel tree requires much more than the ability to fork it to start with, because there are numerous patches than need to be synchronized. An unmaintained tree becomes uncompileable very quickly. You can't just open another branch to show your alternative exists, you have to continuously merge in the mainline tree's changes and change your code to make sure it still works. The work of actually running the merge commands or downloading the changes of the other trees dwarfs in comparison. There are trees of maintainers (e.g., Dave Jones) that do nothing else but keep 2.4.x patches and bug fixes compatible with the 2.5.x changes. I don't see why keeping those alternative trees as CVS branches would be much different than the current situation, much less how they are relevant to the problems that 2.4.x had in practice. > > > Linus can take a look at the patch between the CVS repository and what he > > > checked last time, and pass his comments. And he could do it all the time. > > > > So what? Then he'll okay patches he likes, and revert any change he's > > not yet sure of, and developers would have to recommit them from time > > to time so that he re-examines their patches. You've changed the > > mechanism, but kept all the problems. > > > > No. If Foo Bar who is the architect or maintainer of subsystem Mosesium > (just for the pun - ;-)) commited a patch, and Linus does not like it - > he won't have the authority to immidiately revert it. Besides, like I > said, LT would not need to go over the entire kernel patch. This means that the kernel would no longer have a central authority. It also shows that CVS versus mailing patches is not the central issue, since both development models can be reasonably used with either method. > > Now, there /have/ been attempts to write software that works > > according to Linus's development methodology (e.g., BitKeeper), but > > they have more to do with patch management than source control. > > I want a source control system to be used. I figured as much :) > If Linux is not modular enough - then I think one of the first priorities > should be to make sure the opposite becomes the fact. The question is - > why the code became so unmodular in the first place? I am certain that all kernel hackers are very well aware that that modularity is a Good Thing. But you can't say "let's make it modular" and have it so any more than you can say "let's make it bug-free" and have it so. Linus commented on the problems with increasing modularity a number of times in interviews as well as on-list. > From what I read somewhere and from my impression the kernel or at least > some parts of it were actually well-written. They are very scarcely > commented (which is another thing that should be remedied) Also consider that over-commenting can be a problem as well, and that this is often a very individual issue. I don't know how your idea of the approproate amount of comments compares with my idea of it or of the kernel developers'; you can take a look at various kernel pieces and decide for yourself. > So I'll add the following items to the mutiny's agenda: > > 1. Make the kernel components modular enough. > > 2. Comment the code. I think you will have a better baragining position if you actually have a patch or two (written by you or others) implementing your suggested changes. Asking for changes to done by others will not be effective if those from whom you request the changes disagree. Besides, everybody will have a much better idea exactly what do you mean by your suggestions (how much commenting, which APIs between the modules, and so forth). ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
