Re: [Gnu-arch-users] tla-pqm 0.2

[Colin Walters]

On Thu, 2003-10-16 at 22:13, Tom Lord wrote:

> I think this is a good direction but it needs to cook more, along with
> the patch tracker foo.

Do you have any specifics?
For example, would you accept patches to implement "submit-merge" in my
proposed form?  I think that actually the idea of submitting a merge
request is a fairly general one, and other types of arch process
management software could leverage the same architecture (dropping a
file into a queue or sending a GPG-signed email).

> And I'm increasingly convinced that we want an extension language [...]

I think what we really want is for tla to be friendly to extension
languages, rather than requiring a specific one.  tla is already fairly
friendly to scripting, what with parse-package-name and a good
commandline syntax (albeit one that changes fairly frequently :)).  With
some changes in libarch that have been discussed before (like not
aborting on every error), a Python module would be fairly doable.

Slightly offtopic, but: I wish you wouldn't use tla so much as a vector
for the propagation of only somewhat related memes.  It's fine that
you're writing another scheme/lisp implementation; but it should be able
to stand on its own merits, rather than being dragged along with tla.

> [...] in
> which to start writing "process management" customizations.   pqm
> illustrates that.  The notes we've had on archivist illustrate it.
> and the notes we've had on patch trackers illustrate it.

I don't think the difficulty is interacting with tla - the code to do
that in tla-pqm is just a few lines, really.  The harder parts of pqm
are things like parsing emails (which actually Python makes completely
trivial) and validating GPG signatures, and those problems aren't
tla-specific at all.

> People have been talking about integration with eclispe and, well,
> that's fine -- but really i think we want a whole new kind of "project
> management IDE" here.

That would be neat, but we should go for a layered solution, because
some people may not want certain aspects, or may find it too complex or
too limiting.

> "embarassingly behind on merges but just about over the hump towards
>  catching up",

Speaking of, here's a few changes I have:

address@hidden
  tla
    tla--mainline
      tla--mainline--1.1
 
[...]

        patch-38
          [tests] first cut at some inventory tests
 
        patch-39
          implement multiline inventory regexps
 
        patch-40
          [tests] test symlink outside of tree

signature.asc
Description: This is a digitally signed message part