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

[Tom Lord]

    > Zack Brown
    >> Tom Lord
    >>> Zack Brown

    >>> 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.

Again: you're making up a myth there out of whole cloth.  I'll explain
further below.


    >> 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.

Ok, that's the other part you're missing: the explanation for why
you're making up a myth.

You're assuming that I'm reacting to disagreement.  In the case of
svn, I'm not reacting to disagreement.  I'm reacting to refusal to
understand/consider the issues well enough to form a disagreement, in
the face of ample overtures laying out the basics and offering to work
through the details.

I'm reacting to a breakdown of how civilized engineers in positions of
social responsibility (a condition both I and the svn engineers find
ourselves in) should behave.   I don't see a disagreement:  I see a
breakdown of those extra-economic processes by which engineers provide
checks and balances on the economic authorities within whose domains
they operate.




    > > 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. 

Well, please let me retract the word "ego", then.   I use it in a
particular way.   I think it is not the same way you use it.  Please
just take me as pointing to a problem, where engineers have failed to
live up to the duties imposed by their capabilities:

A bifurcation of effort and resources persists that is not well
supported by a bifurcation of the design space.   The social
implications of deployment under such a condition are, at the very
least, deserving of critical attention.


    > 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

But why not exhibit a better effort at trying to understand its
relationship to related work?


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

That is not a hard or terribly time-consuming problem to solve.


    > 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.

"faith"?


    > 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?

They were not participating, they were obfuscating.  They were not
giving "uptake" to the issues, if that means anything to you.


    > > 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.

Stop putting words in my mouth.   That is not even close to what I
said about the OpenCM project.


    > > 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.

You are.

-t