[MLton] mlton.org server

[Matthew Fluet]

On Sun, Feb 27, 2011 at 2:04 PM, Stephen Weeks <sweeks at sweeks.com> wrote:
> I'd like to bring up the topic of handing off the administration of mlton.org
> (mail, web, svn), so I can stop maintaining the current mlton.org server.  This
> is by no means urgent, but I simply do not have time to do a good job of
> maintaining the server which is becoming more and more stale.  I'd like to
> transfer before the lack of good administration bites us.
>
> Options are to go to another server maintained by someone else, or to use hosted
> solutions for individual services.  I lean toward the latter.  Whatever we do, I
> think it would be good to get something that we believe will work for at least a
> 5-year time frame.
>
> Thoughts?  Volunteers?

I've been thinking about this as well.  I completely agree that the
current mlton.org server isn't serving us well, and the overhead of
administering the whole server (mail, web, wiki, svn, ...) is too
much.  I'm also of the opinion that moving to one or more project
hosting sites would be the right choice.

My vote is to move back to SourceForge.net.  Perhaps not as sexy as
Google, but I think it has a number of advantages:
 * mlton already has a project on SourceForge
 * Stephen and I are both admins of that project
 * The most (D)VCS choices: CVS, Subversion, Git, Mercurial, Bazaar
    - I think we should stick with SVN during the transition, but
should have options for switching after the move
 * Mailman mailing lists with the option to import existing archives
 * Easily accessible content for backups
 * All services hosted under one host
 * Should satisfy the 5+ year time frame criteria.

The only major gotcha that I can see is that the Wiki content is
harder to move.  SourceForge offers MediaWiki (rather than MoinMoin),
but I suspect that we could script most of the conversion.  In any
case, this would be a gotcha with any move, even if only due to the
fact that we're using an old version of MoinMoin on mlton.org so there
would be some upgrade pain.  We'll probably lose most if not all of
our nice wiki macros and also nice syntax highlighting of SML code;
again, I think this would be true for any switch to a hosted wiki
service where we can't install custom extensions.  But, I don't think
it is insurmountable or a block to transitioning.