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

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> I'm taking too long to deal with them because I'm off working
    Tom> on Furth or whathaveyou.

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

Ah, so _delay_ is problem X, not the bugs as such.  I had the wrong
level of abstraction.

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

I don't see any maybe.  Any abstract bottleneck on the critical path
will eventually manifest as delays when the process speeds up.  Or are
you thinking something else?

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

The thread where the word "voting" occurs frequently?  The idea being
that even if there is a BDFL, he can demote managing the patch queue
himself from priority #1 except for some (managable) fraction of time,
thus breaking the bottleneck?

    Tom> Meanwhile, some of my questions (to myself) as arch
    Tom> maintainer are: Why isn't asuffield done yet?  (Why didn't
    Tom> the tla pqm take about 1-3 days to bring up?);

This worries me, if you need to think about it.  Isn't that obvious?
Or do you think you have an architectural solution to the problem that
keeps the SEI, Yourdon, de Marcos, et al in business?

In tla/pqm it's particularly extreme: you've got a whole bunch of
contributors who think at the SEI Managed Level (not Level 5, nobody
here even believes in metrics, right? ;-); you've got a process at
maybe the SEI Repeatable Level (yes, _you_ have it defined in some
useful sense, but that's another way you are the bottleneck, right?);
and asuffield is writing tools to (partially; decision automation is
jblack's pidgen, right?) automate the process at about the SEI
Defined Level.  Presumably that's mainly with input from you, but
specification is also going to require seeing how both other
lieutenants, main contributors, and occasional contributors think
about things.  Traditionally, this specification of a software system
automating a process is considered a very difficult task, isn't it?

(Please don't take the SEI levels seriously.  They're intended to
express quantum differences in organizational level in what might be
familiar jargon---I'll unpack if you think that's interesting/
necessary---not the specific SEI collections of features, or even
necessarily the idea that features map to levels in a monotone
fashion.)

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

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

Yah, I already knew that; the question was a direct consequence of my
brain fart about what Problem X was.

[[  Inquiring Minds Want To Know Dept.

    Tom> Arch already has an extension language: C.

Doesn't it matter that C is (usually) not interpreted?  Or does that
question just unpack to "why doesn't tla bundle [NAME-OF-FAVORITE-
WRAPPER-MACRO-PACKAGE|all known wrapper macro packages]?" (and for
that see "please bundle MACRO-PACKAGE" thread bla-bla-blah).  ]]

[[  Tom> Arch is internally pretty maxed-out on the flexibility and
    Tom> "level" of the [C] code, the "exit on error" foo being the
    Tom> only (quite solvable) exception.

Thanks for saying that---I figured that out before I read it, so nice
warm fuzzy.  :-)  ]]

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

Isn't this risky?  I mean, I realize you are probably as smart as you
think you are (who else could estimate? ;-), but I don't see an
analogous project in your resume.  The point being Guile, Systas,
Pika, furth, these are language implementations, you've done it dozens
of times by now, there's a huge literature too.  Hackerlab, libtla,
rx, library APIs, tons of experience, literature to fall back on.
larch, tla, application/UI, experience, talent, some literature.

But what you're talking about now isn't really an API or a UI, it's an
"application architecture interface" (just for notation).  So "risky?" 
unpacks as

    1.  Isn't this "And Now For Something Completely Different" time?
    2.  If so, how are you estimating delivery date of software product?


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.