> However, the only meaningful way people can productively "play" with > th silver branch is when it is not far from the gold.
I have several systems that are very, very far from Gold. They include interpreter rewrites, algebra rewrites, browser rewrites, etc. The only way to make progress is to move away from Gold, mangle functionality, prove it, merge it, test it, and then promote it. This takes months. My impression was that SVN was going to be a place where people could clone Silver and do their own subsystem, say to explore ideas like working with Sage or a complete rewrite using ALLPROSE.. I don't have the time to look at the Sage idea but someone could do this in SVN and let people play with it. Once it works the way people like then the effort to merge it into Silver and promote it to Gold can start. > Nobody would > want to waste its time on a system that is *for sure* very remote from > the gold. We had a very long email thread about update rates to Axiom. The issue was striking a balance between "immediate fixes" and "reasonable workload". After much discussion we agreed that a new copy of the system would be released approximately once every 2 months. This is not immediate (notice that Gold has not changed since April, despite fixes being applied). This is not slanted toward a reasonable workload (6 months). So patches get collected and the Gold copy is built/tested/ported every 2 months or so. I missed the goal this past month due to preparation for ISSAC and now, due to updates caused by ISSAC. Gold gets released every couple months. Silver can do a simple diff -r --brief Gold Silver to see exact changes. Given the rate of change it isn't possible for Silver to drift far from Gold. On the other hand, Silver can do immediate patches if someone is willing to do them. My objection to immediate patches in Gold is that it takes me several days to "release" a Gold system (due to testing and porting). I don't want to release a broken system. If I took on the responsibility of doing immediate patches to Silver that would completely negate the whole "update rate" balance discussion. You can't just throw a patch at a system. You have to check it. That takes time even for simple patches. For instance, I have a simple fix to the Makefiles for libXpm that makes the system compile correctly on FC5. However, it breaks Redhat systems. So if I just applied the patch to Silver without testing some of the users would have broken code. ; We all agree that we don't have enough resource; the last > thing we want to do is to waste the scarse resources in many wasteful > forks. Resource is exactly the point of the "reasonable update rate" issue. There are things that only I can do and these are things that I should spend time doing. There are things that others can do (like apply patches to Silver) and these are things that I should not be doing. t _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
