Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Andrew Morton <akpm@zip.com.au>]

dean gaudet wrote:
> 
> On Sat, 20 Apr 2002, Daniel Phillips wrote:
> 
> > Riiiiight.  I have at least forwarded your demands to those who have
> > expressed their positions to me privately.  If you think I'm going to
> > violate their confidence on your whim, you can think again.
> 
> so then you're having private discussions in email, and one of your
> complaints is about other private discussions in email?
> 

The reason why people do not express their disquiet is very plain - any
time anyone dares comes out, they promptly get their head kicked in.

Guys, this problem is permanent, and it's not going away.

Larry has stated that kernel's use of bitkeeper is not providing
collateral sales, and nor was it intended for that.  Fair enough.
But it's inevitable that, in some people's eyes, kernel's very
public use of bitkeeper be viewed as promotion of bitmover's
product, and as endorsement of bitmover's licensing innovations.

Some people don't like this, and never will.  I'm tempted here to
say "get over it".  This disagreement is a permanent part of the
kernel landscape.

Linus took the work of others and used it in a way which they did
not expect, without their permission, and contrary to their wishes.
He knew what he was doing, and he knew that some wouldn't like it.
If he had chosen any other path, he'd be juggling ascii diffs
until the end of time.

My take on Daniel's patch is that it is addressing the symptoms,
not the problem.  And the problem is unsolveable.  The differences
of opinion are irreconcilable.  Both sides are populated by 
perfectly sensible people with perfectly legitimate points of view.

So.  Life goes on.  We will have regular bitkeeper flamewars, and
that's a good thing - it reminds everyone that there are different
opinions and different work practices which need to be accommodated.

Oh.  And the problem of stealth patches is a human one, not a tool
one.  Tree owners should prefer to drop unreviewed patches. Not just
because said patches may have bugs which they miss.  Not just because
having others check the work lightens their workload. Not just because
others may have other, different implementations in the works.  But
also because it keeps everyone informed as to what's going on, and
generally makes for a better development team.

It would help to avoid, say, the situation where random fs maintainer
"A" is amazed to discover one day that a patch from random VFS maintainer
"B" had caused said filesystem to be doing a surprise "up" on a non-downed
semaphore.  Not that this could ever happen.

-