[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] etla [Was: Testbed for OverArch]

From: Tom Lord
Subject: Re: [Gnu-arch-users] etla [Was: Testbed for OverArch]
Date: Fri, 14 Nov 2003 17:16:44 -0800 (PST)

    > From: Clark McGrew <address@hidden>

    > TLA is just a little bit to unfriendly for the less computer
    > inclined to work as a "drop in" replacement for CVS (different
    > functionality, same purpose), but it's really close to being
    > ready.  However, I think it needs a nice shiny veneer (that can
    > be regarded as a prototype for overarch).

I think that you may be overgeneralizing from the needs of your
project to the responsibilities of the arch project.

A "veneer" such as you describe would not be merely a "friendlier
front end to arch" -- it would be a "less general front end to arch."

It would not be "a prototype for overarch" -- it would be "an example
of overarch output".

I do not think it makes sense (from the arch-project perspective) for
you say, "Hey, let's start overarch by addressing the needs of my
collaborators."  Rather, I think that (and have been saying that), if
we're to take a bottom-up approach to overarch, many _different_
projects should start by making their own particular veneers
independently and then we can see what generalizations emerge from

When you first posted I posed you a bunch of specific questions about
your software project.   I still think that those questions point to 
the productive way to move forward.

The biggest commercial revision control systems typically require an
"admin", hired for his skills in that system, who acts as a de facto
software process engineer for his employer.  I don't think that's
because those revision control companies chose to not automate the
"process engineer" role -- the role of the guy who comes in and makes
a _site_specific_ veneer (even if just in the form of local usage
conventions).  Rather, I think it's because those companies
_could_not_ automate the role of "process engineer".

Overarch, should it come to pass, will be a tool for process engineers
-- not a replacement for them.   You need a process engineer.

But then look at what you and your collaboratiors will still be saving
on licenses :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]