[Moose-g3-devel] GENESIS development sites and mailing lists

[Dave B. <db...@do...>]

Jim and Michael,

There are some decisions to be made, which have become more pressing due
to the planned move of the genesis-sim.org server (biad181) from UTHSCSA
to UTSA.  There was a flurry of emails on August 17-18 and August 30-31
between Michael, Joe, Hugo, Upi, and Mando. and me.  I'll do my best to
summarize the situation, and give some opinions.  I've copied this email
to the moose-g3-devel mailing list, so that it will go to everyone who was
involved in this discussion, so that it will be archived, and so that they
can point out omissions or errors in my account of what they said.

As I see it, two separate issues came up:

(1) Should the BABEL mailing list be moved to Sourceforge, as is now
the case with the moose-g3-devel mailing list?

In any case, we should change from the present mailing list software, which
is based on my own perl scripts and requires sendmail to be installed on
the server.  We need a standard, well-supported mailing list manager that
deals automatically with bounced mail, subscribes/unsubscribes, etc.
Michael suggested that there may be problems continuing to use the present
system when the server is moved to the UTSA network.  To me, this is the
most urgent issue, because I don't want to see any interuption of service,
or other proiblems, for our users.

Moving it to Sourceforge would be a very easy solution.  We could simply 
set up a mailing list on the same Sourceforge site that we use for the 
GENESIS 2 source code repository and the user forums.  With the exception 
of a short period of problems with sourceforge (see below), this worked out 
pretty well when we moved the genesis-dev mailing list to Sourceforge as 
"moose-g3-devel".  Not only would this save Michael a lot of work, but it 
would help steer our users to the user forums, which haven't been getting 
as much use as they should.  The GENESIS and BABEL web pages have links to 
this site for getting the latest GENESIS OS/X versions and updates from the 
repository.

The disadvantage is that we would have to educate several hundred apathetic
BABEL members to use a new email address at lists.sourceforge.net,
and if we grow unhappy with Sourceforge, then change it back again.

Alternatively, we could run the same mailing list software that Sourceforge
uses (GNU MailMan) and host and manage it ourselves at UTSA.  That would
be more work for us, but would allow us to keep the same email address
for the GENESIS Users Group.

If I could believe that we are likely to stick with Sourceforge, I wouldn't
object to moving it there, while keeping the BABEL website on the the
genesis-sim.org server.

So this raises some questions for Michael that may help us decide:

When is the move likely to happen?  How much time do we have before we
are forced to do something?

Is it a certainty that we can't run the present combination of perl and
sendmail for a while, until we properly set up the new system?  Is it a
problem of administrators not wanting us to run our own mail server
through the UTSA firewall?

Would these same considerations prevent us from running the MailMan
software ourselves from UTSA?

How big of a deal is it to set up MailMan ourselves?  It seems that once it
is set up, it isn't any easier to manage the mailing list on Sourceforge
than it would be to manage it on our own machine.  The big advantage of
Sourceforge is that they have it all installed and set up.  Is that
correct?

(2) Should the site for the MOOSE and GENESIS 3 development (including the
moose-g3-devel mailing list and source code repository) be moved from the
present Sourceforge site to our own server?

We went through a period of problems with Sourceforge around the beginning
of August.  There were frequent downtimes preventing access to the
repository for the MOOSE source code, and a period when the moose-g3-devel
mailing list wasn't getting archived.  These problems have been resolved
(at least for now).  But this led to some discussion, aside from the issue
of the reliability of Sourceforge, of whether we need more sophisticated
tools for collaborative software development than Sourceforge can offer.

Joe pointed out that many of these needs can be met with a wiki, and it
turns out that one can be used with Sourceforge.  Joe has given Michael the
information needed to set one up at the moose-g3 sourceforge site.  Hugo
argued that, in particular, we need a version control system more flexible
than the ones supported by Sourceforge, that is better for distributed
development from many sites.  Most of the others were happy to continue
with the present Subversion system being hosted at Sourceforge, along with
the mailing list.

Upi pointed out that there would be problems with his funding agencies if
the MOOSE development site were moved from a neutral place like sourceforge
to UTSA, or even to his own site.

This makes it clear the the repository and development site for MOOSE must
stay where it is.  At some point, we might want to split the G3
development site off from that for MOOSE, but that seems awfully premature
to me.  I think that any split should come when we have a public release
of something (with a GUI) that we can honestly call GENESIS 3.  At
present, GENESIS 3 is nothing more than the MOOSE core.

As Upi and Greg have made clear, there is a lot more yet to be done in the
way of MOOSE core code development.  I think it would hurt collaboration,
rather than foster it, to separate the GENESIS 3 site from that of MOOSE at
this early stage.  But, we do need a wiki installed on the moose-g3
Sourceforge site.  Michael, can you work on this?

If any of you want to further discuss the issue of collaborative
development tools for GENESIS/MOOSE, please post your comments to
moo...@li..., so that they will be archived.

Dave