Re: [Gnu-arch-users] is there demand for itla?

[Tom Lord]

    > From: Ian Duggan <address@hidden>

    > I think such a thing as you've described it sounds useful. As I
    > understand it, tla would remain the workhorse doing the work of
    > modifying the archive, whereas itla would be more of a hand
    > holding sequencer of commands for common workflows. Sounds good.

That's right.

    > Would overarch then be a declaritive description of how itla
    > should work for a specific project? How would overarch and itla
    > interact with eachother?

I'm thinking that, in the context of itla, it would be more like a
library of Scheme code to make it easier to rapidly write new
high-level itla commands.


    > > The question I'm stuck on is how much "demand" there is for
    > > itla.  Opinions?  Ideas? Rants?  Tips?  I think it's a pretty
    > > exciting idea but I'm not sure what priority to give it
    > > relative to other projects.

    > Given that you are estimating 1-3 months, I think it's important
    > to understand the arch roadmap. I've looked around on the site,
    > google, and mail archives, but I can't find anything like a
    > roadmap or TODO. Is there such a thing? If not, maybe we could
    > come up with/post such a thing and do apache style voting on the
    > roadmap items to set priority?

Wow, that take a bit to reply to.

There isn't too much of a roadmap at this point.  There was --
especially back in the days of larch (the shell version) -- and much
of that has been accomplished.  At this point, there's (roughly
speaking):

        ~ a decent number of people working on ancillary hacks.
          I'll mention pqm as one example but there are several
          others.

        ~ a small number of spit and polish issues that each take a
          more or less single effort to do, but that often show up in
          the bug database as more than one issue.

        ~ a somewhere-in-between number of unfinished tales:  possible
          future directions.   itla is an example of one of those and
          is one that I latched on to because it is a very concrete
          idea doable in a relatively small timeframe.

        ~ lots of floating "political" ambitions (e.g., "kill bk",
          "kill svn", whatever....)

The project is at a sort of cross-roads.   There's many possible paths
for "which way to go next".

The problem of that choice is compounded by a few factors:

        ~ my personal itches:  I would appreciate certain GUI
          functionality and overarch functionality, personally, 
          but for day-to-day foo, arch works just fine for me.

        ~ my resource limitations: It _might_ be hella interesting to
          me to become a kernel or GCC hacker.  Not because I have a
          desire to hack the kernel or GCC, per se, but just because
          it would give me new "arch itches".  It would be a forcing
          function that would give me direct insight into making arch
          suitable for those kinds of projects.  I would want to do
          those things partly for the arch-related spin-offs.

          It's not even close to an option, though.   I don't have the
          disk space.   I don't have the bandwidth to the internet.
          I don't have even a vague approximation of the smallest
          modicum of financial security that would make it sane to go
          down those paths.  Looking at my cash-on-hand (which is
          really all that I have at this point) even the 1-3 months
          estimate for itla looks like a pipe dream.


It feels a bit to me like arch is at a phase transition point: either
it gets recognized by some check-writers and gets some more
substantial backing behind it, or it just kind of trails off into
history until, 3-5 years from now, whoever is working on svn reinvents
it.

As for apache-style voting: nah.  We aren't quite there yet.  The arch
community is too small and there are some loud voices who don't quite
have the arch vision.  It would, I strongly suspect, go widly awry.
Apache has the advantage of being a widely deployed program with a
huge number of design constraints resulting from that, along with the
advantage of aiming to solve a simpler problem -- it's a bit easier in
that context to sort out the sane from the random proposals.  (And,
even so, that's putting an optimistic face on it.  It isn't obvious
that the apache project process is really leading in the right
directions.)




    > Also, maybe someone else could pick up your design and run with
    > it. Might be more reasonable if your expertise is needed on
    > deeper problems.

Oh, I think itla design is a pretty deep problem.


-t