lkml.org 
[lkml]   [2002]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Remove Bitkeeper documentation from Linux tree
    Date
    On Saturday 20 April 2002 19:51, Linus Torvalds wrote:
    > Any suggestions on how to make the process _appear_ less intimidating?

    I'm thinking about it. It's still the best project on the planet, but even
    so, could it be better?

    > Note that one thing that I had hoped BK would do for me, but that hasn't
    > happened because I'm a lazy bastard and I'm bad at doing automated scripts
    > is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
    > since they don't actually add any information except act as update
    > points), and also send out a changelog daily to the kernel mailing list.

    Eeek. That sounds like a lot of work. Oh I see, this is 100% automated.

    > That would actually make the development process MORE open than it was
    > before BK, and might make even non-BK people appreciate BK more simply
    > because there is a real point to it.

    Well, it would be more like working in a fishbowl anyway. The part that's
    missing is the discussion. Just looking at the recent traffic... there's
    Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
    patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
    zerocopy NFS updated", descending from a traditional patch set. The next
    one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
    patches showing up yet, I don't think I need to go on.

    There is a clear inverse relationship between the bk-ness of a patch and
    the extent to which it's discussed on lkml. I don't know what to read into
    that, but it does seem to lend credence to the idea that the bitkeeper
    style of working is not compatible with the idea of community discussion.

    Perhaps there are really two kinds of patches, those that are mainly
    functional and don't need to be discussed, for which Bitkeeper is an
    entirely appropriate medium, and patches-needing-discussion, for which
    the Bitkeeper channel is entirely inappropriate. Most of the volume is in
    the former, and hence, that is where most of the time savings are. The
    corollary of that is, we will not lose a lot of productivity by *not*
    using Bitkeeper for the kind of patch that could or should be discussed.

    > Comments? Anybody want to hack up a script to do this?

    Well, that's a nice thought, but it's not the crux of the problem.

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