Re: [PATCH] Remove Bitkeeper documentation from Linux tree

Rob Landley
2002-04-21T07:40:07Z

On Friday 19 April 2002 06:34 pm, Daniel Phillips wrote:

> I'm not arguing that BK is not a good way to do the grunt maintainance
> work. I think it is, and that's great. Heck, I'm not arguing against
> Bitkeeper *at all*. I'm arguing against building the bitkeeper
> documentation into the kernel tree, giving the impression that Bitkeeper is
> *required* for submitting patches.

I'm under the impression that Linus specifically asked for that
documentation, because BK is a tool he used that he was getting flooded with
questions about.

The question isn't really whether BitKeeper is required for kernel
development, it's a question of whether submitting patches to LINUS is
required for kernel development.

It seems like the BitKeeper documentation belongs together with the other
submitting patches documentation, and should be moved to the directory
"Documentation/Linus".

I.E. explicitly, the Kernel is only interested in documenting bitkeeper to
the extent we're documenting how Linus works. (And it IS how Linus works.)

If you're going to argue about Linus being a single point of failure (and
quite possibly a closed and irreproducible system for which we have not seen
source code), that's a can of worms I'm staying well away from this time
'round, thanks. :)

It might be a good idea if there was a Documentation/SubmittingPatches
directory that mentioned where the various active high visibility trees are
and what they're for (Linus's 2.5 tree, Dave Jones's tree, Marcelo's 2.4
tree, and Alan Cox's come to mind.) But that sort of wanders off into
Maintainers land (to get USB patches in, send them to Greg KH, who has this
email address and whose bitkeeper tree can be pulled from...) With all the
maintenance issues that implies...

> > > The next question you might ask is: are there more BK patches or
> > > more Non-BK, in total, on and off lkml? I don't have statistics at
> > > hand but I'm willing to bet that there are more BK patches, because
> > > that is how the bulk of the grunt tree maintainance is getting
> > > done these days.
> > >
> > > My conclusion: though there are more BK patches being applied to
> > > Linus's tree than non-BK,
> >
> > So... your conclusion is based on a guess which is based on a guess.
>
> Check it if you think I'm wrong.

I think he's saying that the burden of proof about there BEING a problem
rests on the one who is complaining about the problem. Complaining and then
expecting other people to prove there ISN'T a problem is kind of impolite...

> > Even if your conclusion is correct (it might be), how do you use
> > that to support the argument that, less discussion occurs due to BK?
>
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.

And this differs from emailing him a patch without cc'ing linux-kernel in
what way?

Either you trust Linus's judgement about what patches to accept, or you use
somebody else's tree. Did I miss where voting on linux-kernel ever got a
patch in that Linus didn't want to merge, or kept one out that he did?

And AFTER the merge, you still get to flame all you want. And produce a
better patch to "clean up" the old one the way Martin "cleaned" Andre's name
right out of the maintainers file...

I seem to remember Al Viro taking a clue-by-four to Richard Gooch's head over
devfs on a fairly regular basis, and it was generally about the stuff that
had already made it into the tree, not about pending unmerged stuff.

The ONLY reduction in access I can see to Linus's pending unmerged patch
queue is due to the fact that completed patches don't hang around unmerged
for months at a time anymore. And since Bitkeeper seems to have
significantly contributed to lubricating Linus's in-box, I consider it a net
benefit.

Yes, it's a proprietary tool with "source under glass" licensing, but it's
basically a groupware application. Linus might as well be using proprietary
email software: as long as the email he sends and receives is still ascii
text, I can't say it makes a difference to me.

Think data, not applications. The kernel tarballs produced are completely
independent of bitkeeper. Patches contributed to the kernel tarballs have
been made without bitkeeper for a decade, and can still be made and
contributed without use of bitkeeper. The data being transmitted starts and
ends in the same open format as always (C source code in a filesystem->C
source code in a tarball), and the process in between is well understood and
could be done by hand (even with paper and pencil) if necessary. Bitkeeper
just helps Linus to scale.

Proprietary software sucks when you derive work from it in an exclusive and
dependent way. Then they own your derived work. (Like a microsoft word file
you wrote, which microsoft can charge you to access because they own word and
your file is useless without it.) When it's something you can use but don't
have to, it's basically a service. Not owning a service is unsuprising.

In this case, none of the Linux kernel's end product is derived from
bitkeeper. It's just using bitkeeper as an optional tool in the process of
producing that work. It's analogous to using a proprietary bios to boot your
Linux kernel: if it causes a problem, it can be replaced without changing the
kernel being booted in any way.

> > As I mentioned, most merging with Linus occured in private anyway.
> > If you want to argue against that, go ahead. But don't try to blame
> > BitKeeper for it.
>
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.

I sense that the chronic memory management problems of early 2.4 have finally
calmed down a bit, that 2.5 has opened so people have an outlet for CODE
rather than just plans for code, and that rather a lot of the intellectual
bandwidth of the list is currently devoted to keeping up with all the changes
in 2.5 that have already been made or are immediately pending, rather than
speculating about a future that hasn't been coded yet. And that the best
flamewar we've managed to come up with recently (before this one) has been
about the IDE subsystem (far too technical for most people to get really
upset about) rather than something juicy like CML2's use of a version of
Python that Red Hat doesn't ship yet. :)

I also sense that it's spring, the weather's nice and the flowers are
blooming, and certain people might be spending some of their time away from a
computer in a way that isn't as much of an option in the winter...

Rob