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

[Andrew Suffield]

On Fri, Nov 14, 2003 at 11:16:30AM -0500, Clark McGrew wrote:
> What are your plans for etla?  Would you envision it becoming a complete
> command line impementation of the overarch idea?

Not likely. overarch has never been specified, but the impression I've
got from talking to Tom is that it's supposed to be a higher-level
tool.

etla, by comparison, is intended to be a lightweight tla frontend that
reduces common operations to minimal commands - it solves the problems
faced today, and doesn't worry about what we might come up with in the
future. The objective is to have something that's convinient _now_.

> I hope that you update libarch-perl to use tla rather than have native
> support for archives.  

That's actually independent; libarch-perl predates lurch. It's
intended to be a (partial) implementation of arch in perl; the current
dependency on with-ftp is something of a hack (the implementation of
that backend is innovatively disgusting).

> The etla doesn't seem to have any method to delegate actions to outside
> scripts, or to allow package and project based extensions.  Is this a
> design decision, or just not something that has been considered?

Never came up. lurch predates issues like that. However, the design
policy for etla is to focus on individual goals, not to provide
generic facilities. It is not a replacement for the shell.

> My
> thinking is that individual projects will want to define default
> behaviors to match the specific development environment.  For instance,
> a project using a tla-pqm will probably want different newbie
> configurations than a heavily disbursed project without a well defined
> mainline.

Quite possibly, but I can't think of any way in which that relates to
anything etla does right now. I'll worry about it if the problem ever
arises. (Yes, this is intentionally short-sighted).

> Does etla include the possibility for the package, user and site to
> define commands and stash configuration information?  I'd like to have a
> way for projects (in my case a physics collaboration) to define default
> behaviors (like archive locations, tagging-method conventions, &c).

I don't plan on providing an arbitrary extension mechanism, and I
can't think of anything useful to do with =tagging-method offhand. A
more intelligent way of selecting default archives has been on the
todo list for a while, I'm planning on implementing that shortly.

"Project policy" sounds like an overarch thing, though.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature