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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
