[Gnu-arch-users] itla is not overarch

[Tom Lord]

This is a followup to my previous message expanding zander's example
of a "command that prompts" into itla and also a further reply about
Clark McGrew's needs.

I just wanted to briefly clarify the "overarch" concept by explaining
it in that context.  Itla could make overarch a lot simpler to
implement, but wouldn't itself be overarch.

I know that this is a radical opinion but I don't think that things
like command verbosity are really the serious barrier to newbies
fleeing CVS and using arch.   Those might be easy targets on which to
focus frustration, but I don't think they're the deep problem.

The deep problem, I think, is more that what arch _does_ and what it
encourages is fundamentally more complicated than what CVS does and
enourages.

Some examples:

        ~ revision library management
        ~ mirror management
        ~ branching composite projects using configs
        ~ updating/commiting composite projects

and really critically:

        ~ setting up patch-flow infrastructure instead of having
          everyone dog pile on a small number of shared branches

I think that all of those areas -- all the concepts they entail --
just seem foreign and weird if you're coming from a CVS background.

As a result, much of the functionality of arch and its structure
(e.g., the namespace structure) just come off as completely
extraneous.   People don't really know what any of that stuff is for
when they start;  and so having to use commands designed to make those
things easy to work with seems like gratuitous "verbosity".

* So What is Overarch?

  In a perfect world, if some programming shop was being set up,
  it might go something like this:

        day 1) Hire an arch administrator to come in and learn
               what the shop is trying to accomplish with its
               project, what hw resources they have, where and
               how people plan to work, and so forth.

        day 2) The arch admin designs some "shop rules" about 
               how this shop will use configs;  where the
               main archives are and what's the policy for
               cycling them; what notifier-type daemons to run;
               how workers should set-up and name their 
               archives and branches;  etc.

        day 3) The arch admin assembles some shop-specific
               tools and writes a 5-page process manual 
               for programmers in the shop.   The intention
               is that programmers don't _have_ to grok
               arch deeply.  They can instead use an interface
               that reflects the high level process of the shop:

                  % get-bugfix-tree issue582 ~/wd/issue582
                  % cd ~/wd/issue582
                  [hack hack hack]
                  % submit-bugfix

               instead of:

                  % [make branched versions tagging all the
                     parts of the project config.  Be sure
                     to give them branch-name "issue582".]

                  % [tla get the top level;  build the config]

                  [hack hack hack]

                  % [ tla catcfg | xargs ... commit ]


  The catch here is that the tools and rules that admin makes, such as
  "get-bugfix-tree" are not capturing some convenience command that I
  rudely left out of arch: they're very much "shop specific".  When
  the arch admin moves to his next job he's likely to take
  "get-bugfix-tree" with him: but he's also likely to change it at
  least slightly for the needs of the next shop.  In some cases he'll
  have to change it radically.

  So what is overarch?  Overarch is a tool for rapidly assembling
  tools like "get-bugfix-tree" based on very high-level decisions.
  The admin should be able to spell out a few basic rules about
  how archives are allocated, how arch names are used, about how
  configs are named -- and the "get-bugfix-tree" tool generated from 
  that.


* Overarch and ITLA

  If ITLA were extensible in the way that I described and based on
  a really good programming language, then perhaps overarch could
  take the form of extension libraries for itla.

  For example, a programmer might put in is ~/.itla file:

        (load "gnu-arch-rules.scm")

  which would in turn load "overarch.scm" as a library and then
  use it to define commands like:

        (itla) arch be-contributor
        directory for you archives?:  ~/{archives}
        [...]

        (itla) arch be-contributor
        you already are an arch contributor


        (itla) arch make-bugfix
        issue number? (none): 
        bug summary: spelling error in `commit -H' output
        short-name for bug fix: commit-spelling
        
        you already have a branch named `commit-spelling'

        short-name for bug fix: commit-spelling2
        directory for working dir? (~/wd/commit-spelling2): 

        [.... hack hack hack ....]

        (itla) arch submit-bugfix commit-spelling2

        you have uncommitted changes in ~/wd/commit-spelling2.
        are you sure you want to continue? (y/n): n

        (itla) [etc.]

  Of course, the programmer might also have in his ~/.itla file:

        (load "rhythmbox-rules.scm")

  and a command like:

        (itla) rhythm make-bugfix

   might do something quite different in detail from:

        (itla) arch make-bugfix




-t