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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:17 EST