On Sat, 19 Jan 2002, mulix wrote: > [/me replies against my better judgement. oh well] > > On Sat, 19 Jan 2002, Shlomi Fish wrote: > > > I believe that the way things are done in the kernel development have to > > change in many ways to make its maintainance more scalable and > > straightforward. There should be: > > 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. One cannot maintain a piece of software of the scope of the Linux kernel without using CVS. Like I said, I now also uses CVS for preparing my SICP homework, which consists of very small Scheme programs, and a TeX document. Moshe Zadka told me that he uses CVS for every C program he writes at home. > > 1. CVS. > > why? you haven't given *one* compelling argument why kernel hackers need > a cvs. as adi aptly put it, linus is a "cvs with taste". no source > control system will replace him. > A human being cannot effectively replace CVS. 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. 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. > > 2. Roadmaps for the next stable release - what goes in, what stays out, > > etc. > > sometimes there is. it's posted on linux-kernel periodically by linus, > usually in a rather crude form. (bio in, kbuild not yet, etc). > OK, then it can be deleted from the mutiny. > > 3. A general, short, manifesto that explains what Linus thinks the kernel > > should have and what not. (I.e: should it have a sound subsystem? Should > > it have GGI? Should it have an in-kernel GUI?). Just kidding about the GUI > > part. > > i think it's pretty obvious what should be in a unixish kernel and what > shouldn't be. > 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. > > 4. Maintainers of different subsystems who may delegate authority to other > > people. > > we have that. > OK, but I'll explain what's wrong with this system. Continuing the analogy of Moses and the Israelites: what we currently have is that the Israelites consult the Sarey Asarot. They in turn take _all_ of their problems to the Sarey Meoth, who in turn take all of them to the Sarey Alaphim, who in turn do it to the clan leaders. Eventually, Moses has to OK all of the problems the Israelites encountered. By using CVS, a maintainer of a subsystem can commit his changes without Linus having to OK everything that goes in and out there. > > 5. Making sure Linus need not be bothered with any little patch. Linus can > > read the CVS diffs if he'd like, but people can commit changes without > > asking him. > > 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. At the moment what we have is something like a directory traversal in which each directory has forked its own thread, and they all echo its output to one pipe, which happens to be Linus Torvalds. I don't think it is scalabale. > > 6. Defining well-defined interfaces for the subsystems to interact with > > each other, and explaining what should or should not be done. > > this is called a micro kernel, unlike linux, which is a monolithic > kernel. > 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. > > Did I miss anything? I believe what I proposed is better than the ways > > things are done now. > > yes, you missed quite a lot. > > for starters, explain why your system will be better than the system we > have now, which is not perfect, but works. i also get the feeling you > are not very familiar with the way linux kernel development is done, > except from second and third hand sources. You are right about that. That was only my impression. However, even the fact that the Linux kernel does not use CVS is enough to trigger my opinion bit. And you agree that it is a fact. > may i suggest you take some > time to *learn how its done now*, before proposing a Grand Novel > Absolutely Better Way of Doing Things? > > also, this subject has been hashed to death on lkml. maybe you should > read an archive or three? Did anybody dared to say that he will manage the kernel differently? I am proposing to create a better way whether Linus likes it or not. Linus is not God<tm>. Regards, Shlomi Fish > -- > mulix > > http://vipe.technion.ac.il/~mulix/ > http://syscalltrack.sf.net/ > > ---------------------------------------------------------------------- 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]
