lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Proposal: Linux Kernel Patch Management System
   Date: Thu, 14 Sep 2000 15:45:24 -0700
From: Larry McVoy <lm@bitmover.com>

I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work that way and
you are saying, I think, that BK is only useful if everyone switches. I
don't think that people who are using BK would agree with that statement.
You can use BK to track what Linus releases easily and nicely. In fact,
the trees at BitMover, made by the FSMlab crew (Cort and PPC friends),
are just that. Cort worked up some scripts to deal with the fact that
pre-patches are different from release patches, but other than that,
tracking the Linus releases has been trivial.

Yes, but that's no different from http://lksr.org, which uses CVS, and
which does something similar.

The real value for bitkeeper comes when I start getting patches from
*other* people as changesets, all derived from the same BK "root"
repository. Then I can much more easily merge changes, and do all of
the things which makes BK so nice.

It's this critical mass which is missing; otherwise, my custom scripts
which use RCS and where I only check in those files which I modify are
quite frankly, more convenient right now. BK makes me have to think too
hard, where as CVS and RCS are more intuitively obvious what's going
on. That comes from familiarity and long experience, and I have no
doubt that if I were using BK a lot, I'd get familiar with it too.

The problem though is time. I took a full day's worth of my time trying
to play with BK. That was a significant investment on my part, since I
could have done a lot of other things with that time. And in order for
me to get really familiar with it, I'll have to spend more time. But in
the mean time, for the projects where I was using it, I was pretty much
a solo developer, and if that's all I'm doing BK has no real advantage
of using CVS with a local repository. (Which is why it was very astute
of you to give solo developers the option of using BK without openlogin
if they so desired.)

Now multiply my experience by the several hundred kernel developers out
there, and you can easily see how the kernel development community could
easily have to invest a man-year or more learning how to use BK. But
there's catch-22, in that if we don't have a critical mass of people
using it, then the value of BK is seriously diluted. So when I invested
a day of my time learning how to use BK, that was a decision that made
economic sense only if I thought eventually that a lot of other people
would use it. Unfortunately, the bug-a-boo with the license, and the
fact that some people (and I respect their right to feel that way) don't
feel comfortable with the BK license, means that I may have made a bad
choice economically when I made my decision to learn more about BK. (Of
course, there were other reasons other than pure selfish economic ones;I
was curious, and I think Larry's a good guy, and they both weighed in my
decision to spend time learning more about BK.)

I recall the old story of penguins lined up at the ice floe's edge, each
nudging each other to see who would be the first one to jump.
Eventually one would get pushed in, and if he/she wasn't eaten by a
shark, they would all jump in and they would all get fat and happy.
There seems to be nice parallel to this situation.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.063 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site