While I won't take a position on the petition, the post quoted below
has some practical implications, and some others have been raised that
I'll answer:
Dave Jones observes:
Something I've not yet worked out is why none of the
proponents of arch, subversion etc are offering to run a
mirror of Linus' bitkeeper tree for those who don't want to
use bk, but "must have 0-day kernels".
In my case (I'm the author arch) it's entirely a resource problem.
I simply can't afford it at the moment. Otherwise, it would likely be
a high priority.
Let me share some news for people who might be interested in
alternatives to BK:
At least one kernel contributor has a private arch repository for
kernel work, so it seems to be at least marginally doable. I am
certain that further testing, performance improvements, better
documentation, and some touch-ups to existing functionality are
necessary before I would say "arch is so good that you have no excuse
for not using it for kernel work." Nevertheless, it's interesting
that someone is already experimenting with it and the kernel.
I am working on some tools that will help to implement automatic,
incremental, bidirectional gateways between arch, Subversion, and Bk.
I've written a document that describes the state of arch and the
options that I think exist for getting from its current state to a
state where it is unambiguously the best choice. See:
http://www.regexps.com/survey.html
I would like to hear (off-list) from people who are interested in
eventually using arch for kernel work, but who aren't yet "early
adopters". What milestones or features are needed, in your opinion?
Please be sure to mention in your email if I may quote you or not (the
default presumption will be that I may not, though I may anonymously
paraphrase interesting messages and report aggregate results.)
Thanks,
-t
On Thu, Mar 07, 2002 at 06:25:12AM -0800, Tom Lord wrote:
> Dave Jones observes:
>
> Something I've not yet worked out is why none of the
> proponents of arch, subversion etc are offering to run a
> mirror of Linus' bitkeeper tree for those who don't want to
> use bk, but "must have 0-day kernels".
It's amazing to me that all these people who don't like the license,
or are having a bad day, or are 18 year old boys who can't write code
so they are killing time by being self appointed license police,
all of these people could download BK, spend 5 minutes reading the docs,
and write a 5 line shell script which would export each pre-release and
release as a patch from BK. It's trivial. There's no excuse for anyone
to be whining about the BK license, they can use BK to get the data into
whatever bloody system satisfies their religion and be done with it.
> I am working on some tools that will help to implement automatic,
> incremental, bidirectional gateways between arch, Subversion, and Bk.
Gateways, yes, bidirectional, no. Arch doesn't begin to maintain
the metadata which BK maintains, so it can't begin to solve the
same problems. If you have a bidirectional gateway, you reduce BK
to the level of arch or subversion, in which case, why use BK at all?
If CVS/Arch/Subversion/whatever works for you, I'd say just use it and
leave BK out of it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> > I am working on some tools that will help to implement automatic,
> > incremental, bidirectional gateways between arch, Subversion, and Bk.
>
> Gateways, yes, bidirectional, no. Arch doesn't begin to maintain
> the metadata which BK maintains, so it can't begin to solve the
> same problems. If you have a bidirectional gateway, you reduce BK
> to the level of arch or subversion, in which case, why use BK at all?
> If CVS/Arch/Subversion/whatever works for you, I'd say just use it and
> leave BK out of it.
Okay Larry, reality check here...
We really *DO* need to have more than one source control system available
for people to use.
So maybe Arch and Subversion don't maintain all the metadata BK maintains.
That just means that the $OTHER_SCM->BK gateway process has some manual
involvement. This is no different conceptually than sending a 'plain old
patch' in email to $MAINTAINER.
It is in everyone's best interest to make a functional *bidirectional*
BK<->Arch gateway. (Including you Larry)
This keeps the all the open source zealots quiet, and reduces the support
load of Bitmover to those people that actually *want* to use Larry's stuff
because it's better, not those that use it now because there is no '90%'
alternative.
I'd love to see Larry and Tom sit down in a room and come up with an
*easy* way for $MAINTAINER to take patches from both Arch and BK. (I have
only left Subversion out because I haven't seen anyone from the project
take an interest in making changes for kernel developers)
Now, obviously, my time would have been a lot better spent actually
working on this myself, but I have deadlines, and wouldn't have time to
finish it right now. So, I'm trying to spread some sanity around in the
hopes it is contagious. (doubtfull, but I suppose I'll try)
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
On Wed, Mar 06, 2002 at 10:56:52PM -0600, Troy Benjegerdes wrote:
> > > I am working on some tools that will help to implement automatic,
> > > incremental, bidirectional gateways between arch, Subversion, and Bk.
> >
> > Gateways, yes, bidirectional, no. Arch doesn't begin to maintain
> > the metadata which BK maintains, so it can't begin to solve the
> > same problems. If you have a bidirectional gateway, you reduce BK
> > to the level of arch or subversion, in which case, why use BK at all?
> > If CVS/Arch/Subversion/whatever works for you, I'd say just use it and
> > leave BK out of it.
>
> Okay Larry, reality check here...
Go use arch and find out if you really want it. Using arch at this
point is about as smart as using BK 3 years ago. Cort did it 2 years ago
and that was painful enough. To foist arch at this point on people is
actually the fastest way to kill it as a project. These tools take time
to mature and if you want to help arch be prepared to do the same amount
of work that Cort did with BK. It was a lot of work and time on his part.
And why Arch and not subversion? Subversion has more people working on
it, Collab has put a pile of money into it, it has the Apache guy working
on it, and Arch has one guy with no money and a pile of shell scripts.
Come on. There is nothing free in this life, if one guy and some hacking
could solve this problem, it would have been solved long ago.
I don't like gateways because they force everyone down to whatever
is the highest level of functionality that the weakest system can do.
It's exactly like a stereo system. You don't spend $4000 on really nice
system and then try and drive it with $5 of speaker wire. It will suck,
it's as good as the weakest part. In spite of your claims to the contrary,
Troy, it is really not in our best interests to make a BK<->$OTHER_SCM
gateway if that means that BK now works only as well as those other
SCM systems. That's just stupid. If you want to do that, you do it,
but don't foist the work off on me by trying to pretend it's good for BK,
it's not. Diluting BK down to the level of average SCM is completely
pointless and a waste of time.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
I have the sense that you (lm) are trying to draw me into a flame war
on an inappropriate mailing list. I'm not interested.
I agree with this:
lm:
Go use arch and find out if you really want it.
[http://www.regexps.com/#arch -- the artwork (which is not
mine) is worth the price of admission.]
But caution early adopters to read this:
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-09/0856.html
For humor, let me add the juxtaposition of this:
lm:
Arch has one guy with no money and a pile of shell scripts.
with this:
lm:
More than a year ago, we had some research done to see what it
would cost to reproduce BitKeeper from scratch. At that point,
it was estimated to be about $12,000,000 and at least 3.5
years from the time a good team started.
That sounds to me like the kind of research you'd want to include in a
proposal to potential investors: to prove that you have a unique
strength in the market being addressed (a "barrier to entry"). I find
the apparent urgency and hysteria with which you defame arch on this
list to be pretty funny.
-t
Date: Wed, 6 Mar 2002 21:32:38 -0800
From: Larry McVoy <[email protected]>
Cc: Tom Lord <[email protected]>, [email protected], [email protected]
Mail-Followup-To: Larry McVoy <[email protected]>,
Troy Benjegerdes <[email protected]>, Tom Lord <[email protected]>,
[email protected], [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-UIDL: 3e59c456006ecac71f192a6a0da64314
On Wed, Mar 06, 2002 at 10:56:52PM -0600, Troy Benjegerdes wrote:
> > > I am working on some tools that will help to implement automatic,
> > > incremental, bidirectional gateways between arch, Subversion, and Bk.
> >
> > Gateways, yes, bidirectional, no. Arch doesn't begin to maintain
> > the metadata which BK maintains, so it can't begin to solve the
> > same problems. If you have a bidirectional gateway, you reduce BK
> > to the level of arch or subversion, in which case, why use BK at all?
> > If CVS/Arch/Subversion/whatever works for you, I'd say just use it and
> > leave BK out of it.
>
> Okay Larry, reality check here...
Go use arch and find out if you really want it. Using arch at this
point is about as smart as using BK 3 years ago. Cort did it 2 years ago
and that was painful enough. To foist arch at this point on people is
actually the fastest way to kill it as a project. These tools take time
to mature and if you want to help arch be prepared to do the same amount
of work that Cort did with BK. It was a lot of work and time on his part.
And why Arch and not subversion? Subversion has more people working on
it, Collab has put a pile of money into it, it has the Apache guy working
on it, and Arch has one guy with no money and a pile of shell scripts.
Come on. There is nothing free in this life, if one guy and some hacking
could solve this problem, it would have been solved long ago.
I don't like gateways because they force everyone down to whatever
is the highest level of functionality that the weakest system can do.
It's exactly like a stereo system. You don't spend $4000 on really nice
system and then try and drive it with $5 of speaker wire. It will suck,
it's as good as the weakest part. In spite of your claims to the contrary,
Troy, it is really not in our best interests to make a BK<->$OTHER_SCM
gateway if that means that BK now works only as well as those other
SCM systems. That's just stupid. If you want to do that, you do it,
but don't foist the work off on me by trying to pretend it's good for BK,
it's not. Diluting BK down to the level of average SCM is completely
pointless and a waste of time.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Mar 06, 2002 at 09:32:38PM -0800, Larry McVoy wrote:
> > > > I am working on some tools that will help to implement automatic,
> > > > incremental, bidirectional gateways between arch, Subversion, and Bk.
> > >
> > > Gateways, yes, bidirectional, no. Arch doesn't begin to maintain
> > > the metadata which BK maintains, so it can't begin to solve the
> > > same problems. If you have a bidirectional gateway, you reduce BK
> > > to the level of arch or subversion, in which case, why use BK at all?
> > > If CVS/Arch/Subversion/whatever works for you, I'd say just use it and
> > > leave BK out of it.
Additional metadata can be stored as comments. i.e. given the right
tools anything that goes from a BK patchset into $SCM can be turned back
into a BK patchset later on. Same holds for the other direction as long
as the comments are preserved.
> And why Arch and not subversion? Subversion has more people working on
> it, Collab has put a pile of money into it, it has the Apache guy working
As far as I could see Tom was talking about bi-directional gateways
between arch, _subversion_, and BK.
> on it, and Arch has one guy with no money and a pile of shell scripts.
That's a pretty harsh statement, especially since critical parts of the
system have already been reimplemented in C or perl. In a way your
comment is almost similar to...
# Writing a new OS only for the 386 in 1991 gets you your second 'F'
# for this term. But if you do real well on the final exam, you can
# still pass the course.
> Come on. There is nothing free in this life, if one guy and some hacking
> could solve this problem, it would have been solved long ago.
Perhaps the time wasn't ripe, ideas and views on SCM systems have
shifted over the years, and yes BK has probably set some new standards
here, but it is always harder to break new ground.
> it's not. Diluting BK down to the level of average SCM is completely
> pointless and a waste of time.
Having an open platform for exchanging patchsets between SCM systems
also allows people to try out different systems. Perhaps they want to
working in parallel with their existing system for a while before
finally moving everything over to the better system.
Jan
On Thu, Mar 07, 2002 at 01:47:07PM -0800, Tom Lord wrote:
> More than a year ago, we had some research done to see what it
> would cost to reproduce BitKeeper from scratch. At that point,
> it was estimated to be about $12,000,000 and at least 3.5
> years from the time a good team started.
>
> That sounds to me like the kind of research you'd want to include in a
> proposal to potential investors: to prove that you have a unique
> strength in the market being addressed (a "barrier to entry"). I find
> the apparent urgency and hysteria with which you defame arch on this
> list to be pretty funny.
Hmm, maybe I am urgent, I'm packing for a long weekend. Anyway, you're
missing my points, and I don't see why, it's in your best interest to
get it. Let's try it as a question, and see if that works.
Suppose all the kernel people started using your tool today. On your
web page, you have a long list of things which need to be done to Arch
and your best case scenario is that it will take about year to do them
(your words, not mine). So suppose the kernel people start using
your tool right now, bury you in requests for changes, and you can't
keep up. They leave because it doesn't work. End result: big negative
endorsement from the kernel team. Obviously, you don't want that, and
equally obviously, you understand the probability of that (read your
own website), so maybe with all that, you'll understand why I said that
if you want to succeed you should pick a small group and work with them
closely until Arch is ready.
OK, let's address your other point. It sounds like you think we're trying
to convince VC's of something and somehow doing so means that I need to
be badmouthing Arch. Or maybe you think we have VC's leaning on us and
they are telling us that we'd better kill Arch. Or some such thing, the
implication being that investors (or lack of them, or desire for them)
are causing me to go after Arch. That's not true, we are not now and
were not then in discussions with VC's, the only investment BitMover
has is from engineers who work here on the code. We're self supporting
through sales of the product and we are not dependent on or subject to
the whims of any VC. And we've declined offers to be bought so we could
stay that way. Go read the ArsDigita archives and you will understand
why.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> And why Arch and not subversion? Subversion has more people working on
> it, Collab has put a pile of money into it, it has the Apache guy working
> on it, and Arch has one guy with no money and a pile of shell scripts.
> Come on. There is nothing free in this life, if one guy and some hacking
> could solve this problem, it would have been solved long ago.
I didn't include subversion because no one has volunteered help make
gateway stuff from the subversion project. Let's concentrate one gateway
setup first.
> I don't like gateways because they force everyone down to whatever
> is the highest level of functionality that the weakest system can do.
> It's exactly like a stereo system. You don't spend $4000 on really nice
> system and then try and drive it with $5 of speaker wire. It will suck,
> it's as good as the weakest part. In spite of your claims to the contrary,
> Troy, it is really not in our best interests to make a BK<->$OTHER_SCM
> gateway if that means that BK now works only as well as those other
> SCM systems. That's just stupid.
It is not my intention to force any kind of a 'lowest common denominator'
setup. Going from a system with fewer capabilities to one with greater
capabilities (i.e., currently arch->bk) is going to require some manual
intervention from $MAINTAINER.
What I'd like to see is someone volunteer to help develop gateway scripts
(where did all those patchbot people go now?). Then I'd like to see
someone volunteer to be a maintainer to run a gateway so that people that
feel arch is a better solution can use it, and those that feel BK is a
better solution can get on with life and not leave anyone out because they
may have issues with the bk license, or even real technical issues with
BK.
Obviously using arch is going to be harder, because it is nowwhere near
mature as BK is. Some people are willing to make that tradeoff.
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
On Thu, Mar 07, 2002 at 05:09:15AM -0500, Jan Harkes wrote:
> Additional metadata can be stored as comments. i.e. given the right
> tools anything that goes from a BK patchset into $SCM can be turned back
> into a BK patchset later on. Same holds for the other direction as long
> as the comments are preserved.
That's where we disagree. I would encourage you to try it and learn for
yourself that diff&patch != BK. I can say that it won't work and you
simply won't believe me. Please, go try it, you'll see what I mean.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]> writes:
>And why Arch and not subversion? Subversion has more people working on
>it, Collab has put a pile of money into it, it has the Apache guy working
>on it, and Arch has one guy with no money and a pile of shell scripts.
>Come on. There is nothing free in this life, if one guy and some hacking
>could solve this problem, it would have been solved long ago.
One of the most important reasons why packages like CVS, RCS (and SCCS
and I do intend the pun. ;-) ) don't die is C-x C-q and the vc package.
The fact that bk is SCCS compatible here is IMHO one of the really big
positive points.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20