Re: [Axiom-developer] CVS, Arch, Darcs

[root]

Juergen,

>I would strongly support Camm's views on a more modular
>approach. With extremely limited development resources,
>if it takes month to port a little C application (sman)
>to Linux (which should require maybe two days of work),
>we should clearly focus on making things simple. This 
>is not to criticize Tim for not being able to spend more
>time on this -- I myself have not found almost any time for
>Axiom during the last months.

modular and integrated are orthogonal issues. GCL includes many
other projects like the TK toolkit, gmp, etc. From axiom's view
GCL is a modular piece but it needs integration work to build 
smoothly and end users shouldn't do that.

as to the apparent time factor...
unfortunately in the current development method, namely locally on my
machine, all anyone ever gets to see is the endpoints. that gives the
impression that nothing is happening which is anything but true. sman
took so long because i've been working on a MAC port (which I'm
working with a fellow in australia), a BSD port (a fellow in the UK)
and a Windows port (me, myself, and i in the US).

sman has existed for a while but i had to rip it out of the local
code, make sure it is clean enough, test it and publish it.  

These things take time because i have to learn how to use a MAC (which
i find completely unintuitive, frankly) and Windows (which is a steep
learning curve). i'm quite far along on the hyperdoc process (it's
compiling as i write) but you can't see that anything is moving. arch
will at least solve the visibility issue.

>I'm not an expert on CVS, Arch, Darcs. But my impression
>is, that we spent more time on changing the systems used
>than on using CVS on nongnu.org in an efficient way.

there are a couple reasons to move to arch from the project point of view.

first, it enables me to "comb" out the pieces of the system into
separate branches. since arch handles branches much easier than CVS i
prefer it. this will allow myself and others to publish a dozen or
more branches of the development, any one of which is badly broken but
doesn't affect the main build (or the savannah CVS).

second, there is no reason why someone couldn't create a new branch to
investigate some interesting development (say, a logic-algebra
branch). while it is technically possible to do this in CVS the arch
system seems to have a stronger ability to handle branching and
joining.

third, arch supports changesets. if you look at the last 2 dozen items
in the CHANGELOG it isn't clear to anyone except myself which of those
changes are related to sman and which are not. i suppose if i had more
time and were better organized i could simulate changesets in CVS but why?
the kernel people have found changesets so compelling they switched to
using bitkeeper.

the downside is that arch has a fairly painful learning curve.  it is
supposed to be "self documenting" but i've found it to be a painful
startup experience. ah, well, i had the same complaint about SCCS,
RCS, mget, SourceSafe, CVS, and bitkeeper.

>I would argue in favor of using out of the box tools (gcl,
>notangle etc.). Development on one Linux platform only 
>-- others can send patches for other Linux platforms and
>other operating systems (BSD, OS X, Windows) and test
>these. 
>

well, i do the development on my main box which is Linux Redhat 9.  
i have a local "compile farm" in my basement that supports a few other
linux distros and i try to test axiom changes on them before i inflict
them on the rest of the world.  clearly others could "send patches"
but my experience has been that i become involved in the other
platforms anyway. Camm, Mark, Chuck, Bill, and several others have
been very helpful, especially in giving me advice and access to 
equipment i don't have available locally.

t