RE: The direction linux is taking

[John Alvord]

On Tue, 18 Dec 2001, Dana Lacoste wrote:

> > > > 1. Are we satisfied with the source code control system ?
> 
> > > Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
> > > a good job with source control.
> 
> > Not really. We do a passable job. Stuff gets dropped, lost, 
> > deferred and forgotten, applied when it conflicts with other work
> > - much of this stuff that software wouldnt actually improve on over a 
> > person
> 
> So the same result then :
> We are 'satisfied with the current source code control system'
> because there isn't a way currently available that would allow
> for any significant benefit.
> 
> > > Although this seems annoying, it's just one facet of the
> > > primary difference between Linux and a commercially based
> > > kernel : if you want to know how something works and how
> > > it's being developed, then you MUST participate, in this
> > > and other mailing lists.
> 
> > That wont help you - most discussion occurs in private because l/k 
> > is too noisy and many key people dont read it.
> 
> ...but if you are working with the code and you see something change
> the mailing list is the place to ask, correct?
> 
> What I'm saying isn't so much that the mailing lists are complete,
> but that you have to keep current with the community if you want to
> keep current with its work.
> 
> > > There is no central product, so there can be no central bug track.
> > > (see below)
> 
> > Rubbish. Ask the engineering world about fault tracking. You won't get
> > "different products no central flaw tracking" you'll get 
> > extensive cross
> > correlation, statistical tools and the like in any syste, 
> > where reliability
> > matters
> 
> > Many kernel bug reports end up invisible to some of the developers.
> 
> Many kernel developers don't read LKML.
> Isn't that their flaw?
> 
> Many bug reports don't end up in the right place.
> (i.e. a Sparc patch on the LKML but not the Sparc-Linux mailing lists)
> 
> How is a central bug repository going to help?
> 
> For example. Red Hat's knowledge base is a piece of crap.  It's
> impossible to find anything because of the millions of variations
> on different products.
> 
> You can't maintain a central bug repository for separate product
> streams (Red Hat's kernel vs. "Stock" vs. Suse vs. VA, etc)
> because there's too many variables.  If you want a centralized
> bug tracking system then you MUST use the same product or it
> will end up tracking end-user bugs instead of developer bugs
> because the developers won't use it.
> 
> I sincerely challenge you to propose a method for centralizing
> bug tracking in the Linux kernel that _can_ be used by the
> community as a whole.  That means something that Linus would use
> _and_ somebody who doesn't subscribe to LKML can use to find out
> why he can't compile loop.o on his redhat 7.0 system with the
> kernel he got from kernel.org a few weeks ago.

A little while ago, Linus argued (apparently) seriously that chaotic
development gave a better result that more tightly controlled
methods... That a larger space of solutions was searched and better
optimums were found.

Maybe the current development environment is planned chaos.

john alvord