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    [W:0.028 / U:0.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site