lkml.org 
[lkml]   [2001]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: The direction linux is taking
Date
> > > > 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.

> really ?
> Do you know what good source control is ? i doubt it.

why do you drop to personal insults? are your arguments that weak?

i'm a perforce admin. if you don't know what perforce is, you go
look it up. i used to be a CVS admin. i REALLY hope you know what
THAT is. and i've used clearcase and even SCCS/RCS in the past.

my point wasn't that marcelo and linus and allan are source control
systems. my point was that if you're looking for a properly source-
controlled project, THEN DON'T USE LINUX AND QUIT YOUR FUCKING WHINING.

(ok, that might be a bit harsh, but there have been quite a few
people here who think that the linux kernel should be maintained
in the same way as a closed source commercially run project. But
if it was, it wouldn't be _Linux_ any more.)

Linux is maintained by Linus (2.5), Allan (2.2), and Marcelo (2.4)
(and someone's doing 2.0 still, but i forget who :)
That's The Way It Is (tm) and trying to change that isn't going to
happen any time soon (nor, given the disparity between the
Linux Kernel and the Linux Distributions, should it be)

> >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

ahhh, so trying to tackle these problems would be a good idea.
For example, Marcelo's adoption of the "final -pre is (essentially)
unchanged when it becomes the formal release"

Q - Would CVS or Perforce or BitKeeper help fix these problems?
A - No, the problem is one of organization, not accountability

Maybe we should toss the original question and try to find ways
to solve the organizational problems instead?

> >Many kernel bug reports end up invisible to some of the developers.

> that is exactly my point.

so maybe we should make it clear (in the maintainers file, for example)
WHERE patches and bugs should be reported?

It sounds more like a reporting problem than a tracking problem : the
maintainers know which bugs have been fixed (or patches to fix the bugs
have been applied at least) so the only thing missing is that the
maintainers
have to know about the bugs. I don't think that a bugzilla-type central
bug reporting tool will help that, because the maintainers who don't read
LKML won't pay attention to bugzilla either.

--
Dana Lacoste
Ottawa, Canada
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:14    [from the cache]
©2003-2011 Jasper Spaans