Messages in this thread |  | | From | devnull@spaans ... | Date | Thu, 14 Sep 2000 19:21:51 -0400 | Subject | Re: 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/
|  |