Re: [Gnu-arch-users] [Fwd: SourceForge.net Service Update: CVS]

[Zack Brown]

On Sun, Sep 21, 2003 at 01:36:19PM -0700, Tom Lord wrote:
> 
> 
> 
> 
>     > From: Zack Brown <address@hidden>
> 
> 
>     > Each project has its own set of goals, and those goals don't
>     > overlap as much as you might think. So in practical terms,
>     > there's no compelling reason why any of them should abandon what
>     > their doing, in order to go do work on one of the others.
> 
> I think that what you're missing when you reach that conclusion is an
> understanding of arch as separable components that can be described as
> interoperability specifications and fundamental capabilities based on
> top of them -- arch as generic architecture rather than specific
> realization of that architecture.

That's a great feature of arch, but it's not the holy grail. Other projects
have other ideas, and they disagree with you. It's not about ego (as you
claimed), it's about believing something else.

You seem to have the attitude of "but my idea is the best, therefore
anyone who disagrees is doing so out of ego." You see, it's *your* ego
that's involved, not theirs.

> Let me try to expain it this way:
[very interesting description snipped]

> Now, let's suppose you have a problem you want to solve such as "Build
> a revision control system with a recognizably CVS-like user interface;
> with CVS-like access performance characteristics for file contents in
> an arbitrary revision, ....etc."
...
> I claim that it is both practical and worthwhile to consider how to
> solve each of those problems within the context of the arch
> architecture (and, by extension, within the context of existing code).
> Practical because each of them fits in to the architecture (and code)
> in a reasonably clean way.  Worthwhile because, taking that approach
> will have the result that the product system will have the sum of all
> of those features.

I agree with you. But your claim that the other projects were avoiding
this conclusion out of ego, is off the wall. I think a much more likely
explanation is one of the following:

1) the projects are already underway, and the developers don't want to
abandon their work

2) the developers of the other projects don't sufficiently understand
how to map their problems onto the arch system

3) the developers of the other projects don't have faith that mapping
their problems onto the arch system will result in as good a solution as
what they are currently working towards.

Those are all very reasonable explanations, much better than "they
refuse to accept that arch is best because of their egos."

> When I look at something like, say, svn, through the goggles of the
> arch architecture, I think that I break it down just a bit differently
> from the way that they do.  They have some operationally useful
> components -- but very "wrong" APIs between those components and
> corresponding "abstraction leakages".  The clearest example is the svn
> storage manager: conceptually a simple transactional file system with
> inexpensive tree-cloning.  It's in the details, many of which are
> there to solve problems that the arch architecture would locate
> different, that I think the design starts to fall apart (e.g., the
> global revision number; much of the meta-data components....).  In
> practical terms, you could factor out work on such a storage manager,
> simplify its interface, reduce the dependencies between it and other
> parts of the revision control system, and nail it pretty well.
> It'd solve a lot of labor and produce a better result, afaict.

Once upon a time (around when you created the changeset mailing list) you
were working fairly closely with Subversion people, to integrate arch at
the svn back end. Where did that go?

>     > So, all of this seems to add up to there being a different focus
>     > in each project. SVN chases CVS; OpenCM chases their grand idea;
>     > darcs chases its grand idea; and tla chases BitKeeper.
> 
> Although I read your reasoning up to that point of that conclusion, I
> have no idea what that it is supposed to mean.
> 
> tla doesn't "chase BitKeeper" although for some project participants,
> working on a free software alternative to BitKeeper is one source of
> motivation.  That's true for Subversion, too, as far as I know.

I believe Subversion finally bit the bullet on that one, and just gave
up trying to compete with distributed systems, quite awhile ago. That's
why Larry allowed the BK->SVN kernel gateway.

As for tla 'chasing' BK, I meant that tla has as one of its goals, the
satisfaction of the same set of needs that BK satisfies. I didn't mean
to imply that tla tried to imitate BK in other ways, or had BK as its
sole object. Obviously tla is ultimately pursuing it's own set of goals,
some of which go beyond what BK has to offer.

> 
> OpenCM explicitly does _not_ chase a grand idea: it aims at a solid,
> practically studied, and academically published exploration of a
> handful of narrow ideas that arose out of the needs of Eros.

You say tomato, I say tomahto. To them, it's a grand idea. To you, it's
something that should be abandoned in favor of arch.

> 
> From a technical point of view, I'm not sure that breaking down
> projects into "chases BitKeeper" vs. "chases CVS" vs. "chases a grand
> idea" is a helpfully useful distinction.  It seems to rely an
> assumption that there is some important technical distinction implied
> between these various non-technical goals -- I tend to disbelieve that
> assumption.
> 
> The kind of "storyboarding" your doing here, making up a mythology of
> these projects, seems arbitrary and potentially harmful.

I'm just calling it like I see it. I could be wrong.

Be well,
Zack

> 
> -t

-- 
Zack Brown