axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] A suggestion for Gold


From: William Sit
Subject: [Axiom-developer] A suggestion for Gold
Date: Tue, 26 Jun 2007 19:09:43 -0400

The following email (with minor changes) was originally sent
to Tim and he replied: "Post your suggestion publicly. Ask
for a vote. We will go with the majority opinion. You get to
keep the final count."

So please feel free to comment, and may be Bill Page can set
up a sandbox page to keep votes? (sorry, I don't have the
expertise).

William
---

Dear Tim:

What I am proposing may be very drastic and objectionable
from yours perspectives. Still, I think it may be worth your
consideration. All I would like is simply to suggest, in my
uneducated opinion, a possibly more efficient path of lesser
resistance to bring the release version of Axiom up-to-date
asap so we can attract more users and developers.

Given that the consensus (at least 90% by unscientific
observation counts) is that wh-sandbox is the preferrable
version, I wonder how difficult it would be for you to port
(co-opt) your modifications (such as regression tests and
case modificiations) to the wh-sandbox branch and then make
it Gold? Let's forget about documentation for the moment
because documentation slows development efforts. People in
the know can read the code and I agree that in the final
analysis, no matter how much documentation is included, it
is the code that really matters. Documentation will help,
but lack of documentation does not hold back the determined
and knowledgeable. In fact, there is a balance where if
tipped towards too much documentation, then it would be more
time consuming to wade through the verbal explanation than
to read the code itself. So to ask Waldek or Gaby (just two
such examples) to spend their valuable time to fit into your
vision at this time of Axiom development cycle is simply
unwise, even if the horizon is more than 20 years.

The improvement with Axiom is too fast for anyone but the
real
gurus like Waldek or Gaby to catch up with. If Axiom release
mechanism continues on its present course, I am afraid that
many of the improvements and bug fixes will not be
incorporated in a timely manner and this divergence will
only get magnified with time and we may lose developers or
have the project forked.

I know you are worried about correctness, but we can develop
a plan to verify correctness by co-opting resources from the
mailing list and parcelling out specific tests to
individuals. Your regression tests can still be run after
each major rebuild.

So if it is not too difficult, merging your changes into
wh-sandbox would be the fastest way to a new release that
"just works" (this does not mean there will be no bugs, or
old working code will not be broken, but these will be
tested
and then fixed, just like any other bugs). The lack of
documentation is not a big problem because it would be a
waste to document code that is not final (much of
intermediate documentation must be either removed or revised
and if left as part of the historical documentation, will
clutter up the source). Once the "pre-algebra" layers are
seet up and have the right tools for building Axiom, we can
then concentrate on documenting the new source and algebra.

If you can do this, you would be giving the project a big
uplift.

And, thanks to all your efforts (and others), Axiom will
survive, and be better.

William




reply via email to

[Prev in Thread] Current Thread [Next in Thread]