[/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. > 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. > 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). > 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. > 4. Maintainers of different subsystems who may delegate authority to other > people. we have that. > 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. > 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. > 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. 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? -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ ================================================================= 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]
