> > ... it takes a long time to make changes to axiom assuming > > you're going to ensure they are correct before releasing > > them to the world. > > This is the wrong assumption to make about open source. You > are not "releasing" a product, you are doing collaborative > development - hopefully involving many other people. The > quality of the result depends on their participation.
participation is great and i've accepted almost every patch sent to me. i'm hoping to see a drastic increase in the number of tested patches. we differ about the "releasing a product" philosophy. most people either use axiom or they don't. very, very few people will make changes. thus we who make changes have a responsibility to maintain the quality of the system. i'm applying personal standards here but i do not believe we should release anything that isn't the very best we can do. and it should be simple to install, work properly, be fully documented, well tested, and proven as correct as we can. this is computational mathematics, not word processing. it's fine to do anything we want in the silver branch but the golden version should be as close to perfect as we can make it. > > ... > > about every 6 months i finish a major portion of axiom work > > (e.g. the original algebra, the original book, the browser > > recovery, the graphics recovery, the sman "feature complete" > > build, major ports, the tutorial book, etc). there are yet > > more in the pipe and when i sit down to work on axiom in the > > limited time i have available i need to work on big changes > > which make the system more useful and accessible. > > > > It does not make sense that you are trying to do all this by > yourself. If Axiom is going to get anywhere this has to be a > collaborative effort. being open source axiom can be changed in any way by anyone. so far i haven't seen much in the way of patches posted to the list. i HAVE set up almost a dozen separate branches in the tla archive for people who have proposed major changes. some of them have multiple names associated with the branches. i'm assuming that these people are working on their own with the goal of eventually merging their branch with the main line. so far that hasn't happened but it could. why would someone work on a branch and never merge it? the work will eventually get lost. there are 22 people with write access to arch. many have their own branch. it's quite possible for you to make a major system change by integrating the windows changes back into the main stream. you could get it building cross-platform and post patches. we should be able to just type 'AXIOM=.../windows' ; make and get a working windows version. once that works we can try to get the browser/graphics/sman working. but right now, even for me, the windows version feels a bit like a black box. i have a semi-working browser but can't integrate it into the main line until the rest of the windows changes get merged. i have a huge number of goals for axiom. but these are all my own goals (like the internal rewrite, the proviso research, etc). so i'm working to "scratch my own itches". when i complete a major task i merge my changes into the main branch. but until those tasks complete they all occur on my own machines. so far many people such as Bertfried Fauser (clifford algebra), Bill Walster (interval analysis), Chuck Miller (Mac port), Camm (GCL) have all collaborated with me. but only some of those have moved into the working stages yet. i have a textbook on clifford algebra and a textbook on interval analysis open on my desk. i'm learning a lot and writing algebra code but these two problems alone will be multi-year efforts. i've joined axiom to the numerical mathematics consortium (http://www.nmconsortium.org/FldRte/?id=72&page=Associate+Members) because i have an interest in recovering the numerical library facility for axiom. i have rewritten the BLAS library into literate form and have gotten permission from a BLAS person to use his research work as documentation for the routines. i'm in the process of documenting the BLAS code now. when it completes i'll release a numeric library for axiom that is literate BLAS. then i'll move on to the next numerical piece. along the way i'm learning about sensitivity analysis, methods of graphing branch cuts, etc. and trying to add what i've learned to the documentation for the code. for me, axiom opens up whole worlds of interesting work. i'm not trying to be a one-man show but i don't see other patches. i'm amazed that no-one else seems to see the opportunities. or if they do then i'm puzzled why they don't exploit them. anybody can do anything with axiom. my only regret is that my full time job is not axiom. > > if you follow the GCL discussions from the past it is possible > > to re-engineer axiom so it will run on a natively installed GCL. > > to do that you need to: > > > > *) change configure to detect if gcl is installed > > *) change configure to ensure that the native gcl is the > > correct version and patch level > > *) if not, build gcl from zips and apply the correct patches > > > > i would note here that it is NOT acceptable to stop the build > > and insist that the user install/upgrade some other package. > > axiom builds should 'just work'. > > I *strongly* disagree with this. Even the GCL build itself > will stop if it does not find the necessary prerequisits. > Satisfying prerequists is not the job of the build software. > This is handled by other tools like apt-get and yum. well, we'll always disagree on this. always. i have used redhat's rpm, redhat's update, apt-get, and yum. and they all break things that used to work and upgrade packages that i don't want touched. i have a recently installed FC5 system that was intended to be used for axiom porting. after a yum update it is now non-functional. now i have to waste time doing a re-install of FC5. i do NOT want this to happen to an axiom user, at least not because they tried to install axiom. it should 'just work', correctly, cleanly, and out of the box. > > ... > > there is no such thing as a simple job. > > > > There is such a thing as a job that is too large for one > man. oh, absolutely. i will probably not finish half of what i want to do with axiom in this lifetime. but i'm having great fun doing it anyway. t _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
