> > Based on your extensive work would you consider being the > > person who maintains axiom--silver--1? That would settle > > one of the items raised by Gaby. > > > > Yes, however some clarificatinons are needed: > > 1) ATM I work with SVN on SourceForge and I hope to avoid contact > with arch
Arch holds the master sources, which get mirrored everywhere, into CVS on sourceforge and savannah, as well as SVN on sourceforge and google. If you're not willing to do this because of arch then that's fine. I just thought that you were showing great initiative and might find it worthwhile to try. Handling multiple SCMs would be the least problem (currently axiom lives in arch, cvs, svn, and darcs). The hard part is trying to figure out how to agree to things that you disagree with because other people have perfectly rational opinions. Working with arch is trivial. Working with people is hard. And among them I'm probably one of the most painful. > 2) "one of persons who maintain ..." -- IIUC Gaby wants to avoid > single point of failure (me too). How you maintain axiom--silver--1 would be up to you. Be aware that about 22 people have write access to silver at the moment. I don't think "single point of failure" is a rational notion in terms of SCM. You or I could simply stop patching the code and the world would hardly notice since many people have write access. A "single point of control", however, is vitally important. You're basically "putting your name" on the dotted line claiming that you "control" the repository. If you allow anyone to make any change they want you'll quickly find that you have no idea what the changes mean and how they impact the stability of "silver". That behavior is fine in a branch but means chaos in the "pre-production" master copy. You can't track every person's "hot topic", nor have an instant understanding of their "obviously correct patch". You would need to think about how the changes will affect many things including outstanding branches. Suppose someone checks in Java Ant sripts to do builds instead of using autoconf. Is that the best thing for the project? Do we want to add Java as a global dependency? How do you plan to resolve the Perl build mechanism with the current mechanism? Or the build-improvements mechanism? Or suppose someone renames files. What code depends on those files? Does it break things we are not testing? I am very careful about putting patches into silver until I understand them. Silver patches are gold-to-be so its not the same as maintaining a branch. You not only need to apply the patch, you need to figure out how to check that it is right and you need to figure out how to test that it works. Thus a silver patch is very expensive. Just because it works does not make it right for the project. And you have to give strong pushback to maintain quality. Changes and addtions NEED excellent documentation (not just code changes). This will be the big discussion about getting anything into gold in the future. It's a hard job and one that will put you in a position of contention with people at times. Think carefully about it and let me know. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
