RMS and Larry have a little run-in..

[Robert Collins]

http://lkml.org/archive/2003/7/18/260/index.html

[Tom Lord]

Post by Robert Collins
http://lkml.org/archive/2003/7/18/260/index.html

Be aware: there is (unsurprisingly) rising resentment of the
(arguably, not really) off-topic thread on lkml.

Be cautious if you are tempted to join in -- perhaps better if you
aren't.

It occured to me that regarding that thread, and the /. carry-over --
we don't really need to publicize arch there, at this time. Those
threads are a small step in getting a larger community to even begin
to recognize that they have a problem to solve. arch is a solution.
No point in carrying on about the solution until the problem is
recognized.


-t

[James Blackwell]

Post by Tom Lord
Be aware: there is (unsurprisingly) rising resentment of the
(arguably, not really) off-topic thread on lkml.
Be cautious if you are tempted to join in -- perhaps better if you
aren't.

Yeah. This is a nasty, muddy one. Anybody that jumps into this one is
going to get really muddy. Here are some of the more interesting
and/or amusing quotes, taken out of context:

"I think it would be appropriate at this point to write a free client
that talks with Bitkeeper, and for Linux developers to start switching
to that from Bitkeeper."
- Richard Stallman

"Are you really instructing people to go out and violate our license?"
-Larry McVoy

"If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but...."
- Alan Cox

"In Germany there are laws for _everything_. Rules like who owns the
swarm of bees when several swarms of bees unite aren't made at court,
they are explicitely written in laws."
- Adrian Bunk

"Regardless of your legal rights or lack thereof, should you attempt
to reverse engineer BK we'll simply stop giving BK out for free.
See? Simple."
- Larry McVoy

"If you are trying to copy BK, give it up. We'll simply follow in the
footsteps of every other company faced with this sort of thing and change
the protocol every 6 months. Since you would be chasing us you can never
catch up. If you managed to stay close then we'd put digital signatures
into the protocol to prevent your clone from interoperating with BK."

- Larry McVoy

Post by Tom Lord
It occured to me that regarding that thread, and the /. carry-over --
we don't really need to publicize arch there, at this time. Those
threads are a small step in getting a larger community to even begin
to recognize that they have a problem to solve. arch is a solution.
No point in carrying on about the solution until the problem is
recognized.

You're the boss.

Do consider a couple well placed posts by you that simply said "We have a
great option here by the name arch". Doing that verlly well might pull in
a some respectable people that are *very* unhappy right now.

[Zack Brown]

Hi Tom,

Post by Tom Lord

Post by Robert Collins
http://lkml.org/archive/2003/7/18/260/index.html

Be aware: there is (unsurprisingly) rising resentment of the
(arguably, not really) off-topic thread on lkml.
Be cautious if you are tempted to join in -- perhaps better if you
aren't.
It occured to me that regarding that thread, and the /. carry-over --
we don't really need to publicize arch there, at this time. Those
threads are a small step in getting a larger community to even begin
to recognize that they have a problem to solve. arch is a solution.
No point in carrying on about the solution until the problem is
recognized.

I disagree. The last thing we need is YAVCSP (Yet Another Version Control
System Project). When these flamewars come up, people should be told that
arch is here and that it shows real promise. That's the only way to
start to consolidate the frustration into a single, unified project that
has a chance in hell of actually becoming usable.

Be well,
Zack

Post by Tom Lord
-t
_______________________________________________
arch-users mailing list
http://lists.fifthvision.net/mailman/listinfo/arch-users

[Tupshin Harper]

Post by Zack Brown
Hi Tom,

Post by Tom Lord

Post by Robert Collins
http://lkml.org/archive/2003/7/18/260/index.html

Be aware: there is (unsurprisingly) rising resentment of the
(arguably, not really) off-topic thread on lkml.
Be cautious if you are tempted to join in -- perhaps better if you
aren't.
It occured to me that regarding that thread, and the /. carry-over --
we don't really need to publicize arch there, at this time. Those
threads are a small step in getting a larger community to even begin
to recognize that they have a problem to solve. arch is a solution.
No point in carrying on about the solution until the problem is
recognized.

I disagree. The last thing we need is YAVCSP (Yet Another Version Control
System Project). When these flamewars come up, people should be told that
arch is here and that it shows real promise. That's the only way to
start to consolidate the frustration into a single, unified project that
has a chance in hell of actually becoming usable.
Be well,
Zack

FWIW, recent comments on lkml and slashdot encouraged me to take another
look at arch, so here I am. Last time I checked it out was in the
pre-tla era, and it seemed to immature to spend much time on. Much has
changed (for the better), and I look forward to following the arch/tla
development.

-Tupshin
(Perforce and Subversion user)

[Stephen J. Turnbull]

Zack> When these flamewars come up, people should be told that
Zack> arch is here and that it shows real promise.

Arguable.

Zack> That's the only way to start to consolidate the frustration
Zack> into a single, unified project that has a chance in hell of
Zack> actually becoming usable.

Nonsense. Tom has proved that arch is a do-able one-man project, at
least if you get to pick Tom for the man.

IMHO, arch will succeed in proportion to the extent that Tom is sole
authority on architecture. You can't get more unified than that!

NB. I saw very little frustration in that thread, except on the part
of kernel developers who wished the thread would go away.

[Paul Hedderly]

Post by Tom Lord
No point in carrying on about the solution until the problem is
recognized.

I agree...

However I would ask whether arch/tla is the solution to Linus' problem,
yet. Do we know exactly what he likes in Bk? Does tla do that for him
yet?

I guess it's when tla does all that linus needs, and there is some nice
gui and easy conflict resolution stuff, and we can demonstrate that...
that Linux will get interested enough to give it a try.

So perhaps we need a goal list for linux kernel project management.

--
Paul

[Tupshin Harper]

Post by Paul Hedderly

Post by Tom Lord
No point in carrying on about the solution until the problem is
recognized.

I agree...
However I would ask whether arch/tla is the solution to Linus' problem,
yet. Do we know exactly what he likes in Bk? Does tla do that for him
yet?
I guess it's when tla does all that linus needs, and there is some nice
gui and easy conflict resolution stuff, and we can demonstrate that...
that Linux will get interested enough to give it a try.

There might be a lower hanging fruit, and that fruit might be Alan Cox.
;-) I believe that he opted not to use bitkeeper, largely for
political/licensing reasons. It might well be possible to convince him
to maintain his tree in arch/tla before any of the other kernel luminaries.

-Tupshin

[Florian Weimer]

Post by Paul Hedderly
However I would ask whether arch/tla is the solution to Linus' problem,
yet.

I don't think it's there yet. 20 seconds is too much for a whole-tree
'tla what-changed' on a machine which can hold both the project tree
and the pristine copy in the cache (still not too common, requires
~768 MB of RAM, if you include the development tools). However, I
don't know of any _conceptual_ problems that would prevent Linux-style
large-scale use. By "Linux-style" I mean that for each active branch,
there is a respected, central integrator. Projects using CVS (for
example) tend to have no integrator, and arch is probably less
suitable for them at this point.

But I think it's a fatal error to measure arch's success in terms of
adoption by kernel hackers. Kernel hackers are a miniscule target
market, and not necessarily multipliers. Right now, only very few
people use BK despite the example set by the kernel developers. And
there is the risk that the Linux people reject switching away from BK
simply because the alternative is different (or they would lose their
faces).

[Stig Brautaset]

Post by Paul Hedderly

Post by Tom Lord
No point in carrying on about the solution until the problem is
recognized.

I agree...
However I would ask whether arch/tla is the solution to Linus' problem,
yet. Do we know exactly what he likes in Bk? Does tla do that for him
yet?
I guess it's when tla does all that linus needs, and there is some nice
gui and easy conflict resolution stuff, and we can demonstrate that...
that Linux will get interested enough to give it a try.
So perhaps we need a goal list for linux kernel project management.

Not sure about Linus explicitly, but we do know a bit about what the
kernel developers _think_ they want. ;) Have you looked at these?

http://arch.fifthvision.net/bin/view/Arx/LinuxKernel
http://arch.fifthvision.net/bin/view/Arx/MoreLinuxKernel

The latter one is compiled by Zack Brown. Zack, is there any
news on that front?


Stig

[Stig Brautaset]

Post by Stig Brautaset

Post by Paul Hedderly
So perhaps we need a goal list for linux kernel project management.

...

Post by Stig Brautaset
http://arch.fifthvision.net/bin/view/Arx/MoreLinuxKernel

Scanning through this, it looks to me like the only major area arch
doesn't quite meet the "spec" is at the graphical merging tool. However,
I'd like to focus on a different detail that we've talked about before:
The question regarding exchanging changesets via email. Linus don't like
to download patches (he likes them right there in the email), but for bk
changesets he simply gets a link that he `bk pull's or whatever the
terminology is.

Repeating myself: Linus scans a patchset in his mailclient, decides he
likes it, then applies it (the actual changeset he applies might not be
the one in the email body -- it's not for bk changesets now, right?).
Thus, patches in email can basically just be the output of `tla
show-changeset --diffs'[1], with a special arch stanza[2] tacked on.
Then we would have maybe an extra option to `tla replay --exact' or just
extend the syntax a bit to accept the arch stanza as an argument and
apply the changeset.

One thing I think is important is that it should not be necessary to
register the archive -- the new merge/slurp command should be clever
enough to register the archive correctly from the stanza. To avoid
cluttering up peoples ~/.arch-params/=locations, there should be an
option to delete the archive registration afterwards if it didn't
already exist.

Additionally, the actual _real_ changeset might be included as an
attachment to said email. This might be useful for people that do a lot
of merging offline, but it's almost orthogonal to this discussion.

What do you think?

[1] `show-changeset' would need to be able to take an arbitrary version
-- or a command to give that functionality could be introduced
which also adds the `arch stanza' to the output.
[2] James Blackwell introduced the idea of a `tla grab' command that
would work on a `arch stanza', but his idea was a bit different.

Stig

[Bruce Stephens]

Stig Brautaset <***@brautaset.org> writes:

[...]

Post by Stig Brautaset
One thing I think is important is that it should not be necessary to
register the archive -- the new merge/slurp command should be clever
enough to register the archive correctly from the stanza. To avoid
cluttering up peoples ~/.arch-params/=locations, there should be an
option to delete the archive registration afterwards if it didn't
already exist.

The current implementation (in tla, anyway) of ancestry and
ancestry-graph don't work so well if there are unregistered archives
involved. The patch-logs in the project tree don't seem to be used.
(However, things aren't as bad as I previously thought---I had a bogus
registration for one of the involved archives, and that caused the
error message. With unregistered archives, you just get ??? rather
than useful information.)

[...]

[Stig Brautaset]

Post by Bruce Stephens
[...]

Post by Stig Brautaset
One thing I think is important is that it should not be necessary to
register the archive -- the new merge/slurp command should be clever
enough to register the archive correctly from the stanza. To avoid
cluttering up peoples ~/.arch-params/=locations, there should be an
option to delete the archive registration afterwards if it didn't
already exist.

The current implementation (in tla, anyway) of ancestry and
ancestry-graph don't work so well if there are unregistered archives
involved. The patch-logs in the project tree don't seem to be used.
(However, things aren't as bad as I previously thought---I had a bogus
registration for one of the involved archives, and that caused the
error message. With unregistered archives, you just get ??? rather
than useful information.)

Ah, I didn't think of that, but as you say: maybe the patch log
information could be used instead?

Stig

[Tez Kamihira]

Post by Bruce Stephens
[...]

Post by Stig Brautaset
One thing I think is important is that it should not be necessary to
register the archive -- the new merge/slurp command should be clever
enough to register the archive correctly from the stanza. To avoid
cluttering up peoples ~/.arch-params/=locations, there should be an
option to delete the archive registration afterwards if it didn't
already exist.

The current implementation (in tla, anyway) of ancestry and
ancestry-graph don't work so well if there are unregistered archives
involved. The patch-logs in the project tree don't seem to be used.

Point. If it could use the project's patch-logs as well as archives,
we could seek much further ancestors. I don't know whether such implement
is easy or not, though.

- Tez

[Tom Lord]

Post by Tez Kamihira

Post by Bruce Stephens
The current implementation (in tla, anyway) of ancestry and
ancestry-graph don't work so well if there are unregistered archives
involved. The patch-logs in the project tree don't seem to be used.

Point. If it could use the project's patch-logs as well as archives,
we could seek much further ancestors. I don't know whether such implement
is easy or not, though.

It's comparatively trivial. However, in the bigger picture -- it
doesn't work. Eventually you have to trim back those patch logs.

I don't mean it's not worth implementing anyway -- it may be. I just
want to point out that the archives are definitive, and the patch-logs
aren't.

-t

[Bruce Stephens]

Post by Tom Lord

Post by Tez Kamihira

Post by Bruce Stephens
The current implementation (in tla, anyway) of ancestry and
ancestry-graph don't work so well if there are unregistered archives
involved. The patch-logs in the project tree don't seem to be used.

Point. If it could use the project's patch-logs as well as archives,
we could seek much further ancestors. I don't know whether such implement
is easy or not, though.

It's comparatively trivial. However, in the bigger picture -- it
doesn't work. Eventually you have to trim back those patch logs.
I don't mean it's not worth implementing anyway -- it may be. I
just want to point out that the archives are definitive, and the
patch-logs aren't.

Good point. It's worth pointing out that it seems likely that much of
the time, the patch-logs include information that's not available in
archives (at least, not archives that I know about). Arch encourages
people to set up archives, and merge around all over the place, and
the resulting things that we'll see may come from dozens of archives,
some of which might even be private ones (not accessible). And some
may be old archives that don't even exist any more.

So when the patch-log pruning happens, it should take into account the
likely accessibility of archives. Perhaps the pruning ought to be
archiving (to some special place in the revision-library, or something
like it).

[...]

[Tom Lord]

Post by Stig Brautaset
Repeating myself: Linus scans a patchset in his mailclient, decides he
likes it, then applies it (the actual changeset he applies might not be
the one in the email body -- it's not for bk changesets now, right?).
Thus, patches in email can basically just be the output of `tla
show-changeset --diffs'[1], with a special arch stanza[2] tacked on.
Then we would have maybe an extra option to `tla replay --exact' or just
extend the syntax a bit to accept the arch stanza as an argument and
apply the changeset.
One thing I think is important is that it should not be necessary to
register the archive -- the new merge/slurp command should be clever
enough to register the archive correctly from the stanza. To avoid
cluttering up peoples ~/.arch-params/=locations, there should be an
option to delete the archive registration afterwards if it didn't
already exist.

I think this is a good idea.

I'm starting to think I'd like to see something even fancier: a nice
GUI or Emacs mode that helps me manage all of my branches and my
mirrors of the archives of people who contribute to arch.

For example, I'd like just a "point-and-click" list of all the
archives of contributors, listing the archive name and location, the
last time I updated my mirror, and so forth.

If I click on it, I could browse whats-missing (in both directions),
individual changesets, computed changesets relative to my mainline,
notes I might have taken about this archive, etc.

I'd like to be able to select changes and merge techniques and have
the merge invocation automated.

This relates to what you're talking about in the following way: I'd
like to give the little database that backs that interface its own
email address. If you want to tell me about new patches to merge,
you send mail to that address and its noted in the interface.

Conversely, I'd like this tool to be able to generate such email.
For example, perhaps I can select some of my own revisions and push a
button that sends email to the database for some upstream maintainer.
The next time he fires up this GUI, he sees a notice "please review
these patches ..." attached to his entry for my archive.

In other words, I don't want to use my general-purpose MUA for
exchange of this completely regular patch-flow email -- I want to use
what is, in effect, a special purpose MUA.

I realize that's a pretty abstract description short on details -- I
started to write a longer one but it was turning out to be _very_ long
so I stopped. But, get the idea?

-t

[Zack Brown]

Post by Stig Brautaset

Post by Paul Hedderly

Post by Tom Lord
No point in carrying on about the solution until the problem is
recognized.

I agree...
However I would ask whether arch/tla is the solution to Linus' problem,
yet. Do we know exactly what he likes in Bk? Does tla do that for him
yet?
I guess it's when tla does all that linus needs, and there is some nice
gui and easy conflict resolution stuff, and we can demonstrate that...
that Linux will get interested enough to give it a try.
So perhaps we need a goal list for linux kernel project management.

Not sure about Linus explicitly, but we do know a bit about what the
kernel developers _think_ they want. ;) Have you looked at these?
http://arch.fifthvision.net/bin/view/Arx/LinuxKernel
http://arch.fifthvision.net/bin/view/Arx/MoreLinuxKernel
The latter one is compiled by Zack Brown. Zack, is there any
news on that front?

The basic feature needs are still the same. Maybe the documents could be
updated a bit, but I think the problem has grown somewhat broader:

1) BitMover provides a number of additional services surrounding BitKeeper,
and these services are improving all the time. With such a head start as
Larry has, the kernel developers are likely to require quite a large and
robust service infrastructure surrounding any version control engine, before
they'd consider switching engines.

1a) A lot of people depend on the services BitMover provides, not just
kernel developers. Any attempt to switch engines without carrying those
services over, will meet resistence, even from those critical of BitKeeper.

2) The kernel developers have a particular way of handling tree management,
and they will almost certainly insist that any new system support those
methods as well as or better than BitKeeper. i.e. it won't be enough to
say, "well, you can accomplish the same thing if you go through this hoop."
They will want a general purpose tool, not a tool that must be wrenched into
compliance, or that enforces particular work habits.

Those are the main two points. The issue is migrating from basic program
features, to sophisticated interaction and auxiliary infrastructure.

Tupshin Harper mentioned Alan Cox as a person who might use arch. This is
true, because he has staunchly resisted BitKeeper, and supports the idea of
replacing it. Also, for him, there is no existing infrastructure to overcome,
and so he might actually take the program on its merits.

I'd recommend that Tom talk to Alan and get a sense of what would be
required for Alan to use tla. Then put that in a doc, and see where it
goes.

Be well,
Zack

Post by Stig Brautaset
Stig
--
brautaset.org
_______________________________________________
arch-users mailing list
http://lists.fifthvision.net/mailman/listinfo/arch-users

[Tom Lord]

Post by Zack Brown
Tupshin Harper mentioned Alan Cox as a person who might use arch. This is
true, because he has staunchly resisted BitKeeper, and supports the idea of
replacing it. Also, for him, there is no existing infrastructure to overcome,
and so he might actually take the program on its merits.
I'd recommend that Tom talk to Alan and get a sense of what would be
required for Alan to use tla. Then put that in a doc, and see where it
goes.

Alan is a busy guy. I don't think I'm on his radar.

Is there anyone on this list who could reasonably describe themselves
as a personal friend or close business associate or close hacking peer
with Alan? If so, would you like to help build a bridge?

My interest in talking with Alan would be an initially slow-paced,
low-impact email-based casual chat.


-t