Re: [Gnu-arch-users] Status of global and tree aliases

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    >     Tom> It's a classic case of having a problem X and a meta-problem
    >     Tom> Y such that the absense of a solution for Y is most of the
    >     Tom> cause of X.  If that situation is expected to keep recurring,
    >     Tom> and you have only resources to work on X -or- Y, then Y is
    >     Tom> the problem to work on.

    > Would you unpack this?  Colin says there are these concrete bugs, you
    > imply that furth will make them substantially more straightforward to
    > solve, I don't see a connection to any of them.  


Colin says that there are patches pending and known issues to be dealt
with and that I'm taking too long to deal with them because I'm off
working on Furth or whathaveyou.

I agree.... let's call that problem X.

Problem X is a symptom of a larger problem that, in spite of having
ample talent around, I remain the bottleneck for even straightforward
patches.  If I want to concentrate for N hours, days, or weeks on some
topic, then that's N hours, days, or weeks when patches don't get
pushed through and releases don't get made.  That tom-as-bottleneck is
problem Y and X is just a specific symptom of Y.

It's arguable that problem Y is just my problem: that I'm lousy at
time management.  Well, maybe, but I think that that's (mostly) a
hasty conclusion.

The most immediate solution we're working on for Y _was_, until
yesterday, asuffield's pqm for the GNU arch project.   That's looking
a few more weeks away.

Now we have an even more immediate solution for Y because jblack
got fed up with me and decided to go Do The Right Thing.

Meanwhile, some of my questions (to myself) as arch maintainer are: Why
isn't asuffield done yet?  (Why didn't the tla pqm take about 1-3 days
to bring up?);  to what degree will a pqm be a layered system that
users have to learn separately and to what degree does it make sense
to build some of that functionality into core arch?   Those are issues
I'm thinking about while working on furth-and-related.


    > One general reason is that they are quite internal to tla.  Are
    > you redefining the boundary between tla and itla?

A bit, yes.  itla is seeping a bit into tla but in very controlled
ways.


    > Ie, up to this point it has seemed to me that you're fairly
    > satisfied with the operational definition of "inside tla" as
    > what's inside the current implementation.  Or am I missing
    > something else important?

No, I think you're right that there's been a shift in my thinking.
It's an upward-compatible shift, I think, not a reversal.

My original recognition was that some programmability was needed.

I just assumed, then, that a fully general extension language
augmented with arch primitives was called for.  I assumed that would
be [INSERT-FAVORITE-LANGUAGE] plus a sub-process or libryfied tla.
This bundle of goodies would be called "itla".

What was right about my assumption was the nature of the "core of the
core" of arch: there's almost nothing to change there.

What was wrong about my assumption was my belief that anything
substantial at all is gained by adding an extra layer that is a
programming language.  Arch already has an extension language: C.
Yes, it is slightly more difficult to combine separately developed
extensions written in C than it might be to combine separately
developed extensions in lisp (or whatever) --- but aside from that,
given the relatively high-level string and array libraries that arch
uses so heavily internally, it's not significantly harder to write
extensions to arch in C than it would be in Python, Perl, or anything
else.  Arch is internally pretty maxed-out on the flexibility and
"level" of the code, the "exit on error" foo being the only (quite
solvable) exception.

By picking up perl to work on his pqm and buggoo stuff, asuffield
proved that itla wasn't quite the right solution.  To write his
applications he had to make a (limited, special-purpose, one-off) itla
replacement in Perl.  He didn't need any of the features for
interaction that I described --- just "bindings" for arch -- and
consing those up is the easy part of what he did.  In other words, for
all intents and purposes, he _had_ as much itla as would have helped
him --- but then the only gain from having that was that he could
write the rest of his application in a language he happens to like.

So, itla, as originally conceived (and/or until there are tools to
really take advantage of the interaction features I described) is kind
of silly: low necessary cost to implement it (fine!); but also low
payoff for having it (hmm.).

The next thing I thought about (especially around the time of the
"FEATURE PLAN" posts) was how to "package" things like buggoo and the
tla pqm: to make it easy for other projects to set up similar
infrastructures.  I realized that one of the larger issues is
integration: the ideal arch browser would know how to relate revisions
to buggoo issues and the pqm; the ideal pqm browser will know how to
navigate through arch revisions....  It seemed to me (obviously) that
asuffield's daemons could be considered parameterized over things like
"where is the mainline; who are the committers ....." and then generic
code.  Those different parameters mean different things to different
components: pqm has to know where mainline is in order to commit to
it;  a browser has to know where mainline is in order to present data
more clearly.

Hence: thinking about how to configure interoperability parameters in
arch (xl and version variables); thinking about what kinds of
patch-flow "leggo pieces" are suggested by the pqm workl (feature
plans such as submission branches, integration branches, and narrative
branches);  thinking about how to most easily write new high-level
commands that are cognizent of what configuration of leggo pieces is
in play (xl plus side-effects, coming up in the explanation threads
soon); and thinking about how to put all those pieces together.

-t