On Sat, 19 Jan 2002, Adi Stav wrote: > On Sat, Jan 19, 2002 at 03:23:59PM +0200, Shlomi Fish wrote: > > On Sat, 19 Jan 2002, mulix wrote: > > > > > why should its maintanence be more scalable and straightforward? > > > scalability is a nice buzzword, but so is "quality", "cohesion", > > > "direction", which linus supplies in the current system. > > > > I don't think a scalable solution necessarily compromises on quality, > > cohesion and direction. > > Why not? We all want cohesion, quality, direction, scalability, > reliablity, flexibility, simplicity, and rapid development. Shall we > raise the flag of mutiny and demand all those things? You do not > solve real world problems by summoning abstract ideals. Mulix and I > showed how your suggestion could undermine many of the important > qualities of Linux. >
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. > > A human being cannot effectively replace CVS. > > A CVS deals with the mechanism of applying patches. Linus deals with > the decision of which patches to apply. Two completely different > things. > 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. > > Keeping several distinct > > trees is by far inferior to keeping several branches on the same CVS > > repository. If the Linux kernel was a 10,000 lines program which mainly > > only one person touches the code (as is the case for Freecell Solver), it > > can do without CVS. But anything that has a larger codebase or a large > > number of developers must use CVS. > > I don't doubt CVS is an incredible technical convenience. But I don't > see how it is relevant to the problems 2.4 had. Care to bring up some > concrete examples? [1] > 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. > > Read item No. 1 in this link: > > > > http://www.joelonsoftware.com/articles/fog0000000043.html > > > > 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. > I don't see what any of the examples would demonstrate. If you want > to talk about Linux, talk about Linux. You say "CVS is good, everyone > knows that", but you don't show why CVS is good for Linux, certainly > not why it is critically good, which you say it is. > > SEMA is the classical way to develop top-down software. 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. > Linux is the > classical bottom-up software development project. The two are > inherently and completely incompatible. Actually, I'm not even sure > Linux /can/ be developed as top-down. If the source code developemt > happens only at the bottom, then it responds to initiative coming from > the top. If initiative comes only from the top, so must resources. > I know of only two open source projects that really are managed this > way -- OpenOffice and Mozilla. Both are very heavily sponsored by > commercial interested parties. My model can be used whether for bottom-up or top-down software development. > I've heared suggestions regarding IBM > taking over Linux's development, or a consortium of several > interested companies. That might actually be pretty good for Linux, > and lead to good software developed to meet the needed goals, and > remain GPLed. It's just that I much prefer what we have right now. > I'm not saying Linux should become a %100 industrial project. But we can at least be rational and change the model in which it is managed. As it is now, it seems to me that Linus cannot be the ultimate source for every little detail that goes in. It's like Moses having to give his opinion on every minor disputes every one of the Israelites had. 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. > > Linux 2.4.x has everything a UNIXish kernel is expected to have and more. > > Yet, there are other features that other people want inside it. I don't > > claim, that everything that could have been implemented there is there. > > That's why a manifesto is necessary. People so far have placed a > > web-server in the kernel, a CORBA ORB, started to implement a JVM, a 2-D > > graphics subsystem (GGI), etc. Which of these things is acceptable and > > which is not? And generally, which feature that can be propogated to > > userland should still be implemented in the kernel. > > Let me assure you that whether khttpd should or should not be a part > of Linux is a much simpler decision to make than whether Rik's rmap > patch should or should not be accepted. khttpd is just an add-on that > has little impact on the rest of the system. On the other hand, it's > totally clear that a VM is something you /do/ expect to have in > Linux, as it is one of its fundamental subsystems, and this is > precisely the reason why the policy for accepting patches for it is > such a sensitive matter. Linux's fundamental subsystems decide its > general direction much more than a spiffy new kernel web server does. > 2.4 was not delayed due to buggy khttpd or because the ORB wasn't > ready. > 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_. > > > linus WANTS to be bothered with any little patch. it's a crucial part > > > of his quality control system. > > > > 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. > 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. > > Monolithic kernel != Unmodular kernel. > > > > By telling how subsystems should communicate with each other, and what > > side-effects those communications should have, we can make sure that > > everybody is independant of the other developers and can mind his own > > business. > > Well, this is the holy grail of software engineering, is it not? I > don't think Linux is there yet, yet it's a precondition for your > suggestion. > 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? >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) So I'll add the following items to the mutiny's agenda: 1. Make the kernel components modular enough. 2. Comment the code. > > [1] Andrea Arcangeli's new VM, Ingo Molnar's new scheduler, Rik van > Riel's fixes to Andrea's VM, Andrea's fixes to his own VM, Andrew > Morton's low latency patch versus Robert Love's preemptible patch. > Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish [EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] "Let's suppose you have a table with 2^n cups..." "Wait a second - is n a natural number?" ================================================================= 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]
