> What you want is not to merge branch-improvements back to trunk at > this moment. Rather, you want to minimize distance as much as > possible. Concretely, that means backporting some patches on silver > to that branch -- not the other way around.
merging build-improvements can happen "when it is ready" and i suspect it will take a fair amount of give-and-take about things like documentation and philosophy. but i'm not suggesting we start that now. other than the autotools items, it is in our best interest to make axiom--silver--1 and build-improvements identical. so the point of the discussion was that when we make changes they ought to go into the silver branch (which is the next world release) if they can. and the agreed-upon mechanism is to post diff patches against Gold to the mailing list. i don't see this happening and it concerns me. it raises the question of how patches should be done. i believe the point of the SVN repository was that multiple people can create multiple branches to work on different things. these different things would eventually be reviewed and, if accepted, merged into silver and then gold. axiom--silver--1 was created to be a pre-gold version of the system with "early release" of changes so they can be tested. axiom--main--1 is the "official system" so it seems to me that SVN branches should collect up changesets, post these as diffs to the mailing list have these applied to silver review, tested, and finally released as gold. t _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
