[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] itla is not overarch
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] itla is not overarch |
Date: |
Sat, 15 Nov 2003 08:46:39 -0800 (PST) |
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
- [Gnu-arch-users] Testbed for OverArch, Clark McGrew, 2003/11/12
- [Gnu-arch-users] etla [Was: Testbed for OverArch], Andrew Suffield, 2003/11/13
- Re: [Gnu-arch-users] etla [Was: Testbed for OverArch], Clark McGrew, 2003/11/14
- Re: [Gnu-arch-users] etla [Was: Testbed for OverArch], Andrew Suffield, 2003/11/14
- Re: [Gnu-arch-users] etla [Was: Testbed for OverArch], Clark McGrew, 2003/11/14
- Re: [Gnu-arch-users] etla [Was: Testbed for OverArch], Tom Lord, 2003/11/14
- Re: [Gnu-arch-users] etla [Was: Testbed for OverArch], zander, 2003/11/15
- itla (was Re: [Gnu-arch-users] etla [Was: Testbed for OverArch]), Tom Lord, 2003/11/15
- [Gnu-arch-users] itla is not overarch,
Tom Lord <=
Re: [Gnu-arch-users] Testbed for OverArch, Jan Hudec, 2003/11/14