Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

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