Re: [Axiom-developer] Maintainers

[root]

> > 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