[MLton] past and future of mlton.org

Matthew Fluet matthew.fluet at gmail.com
Thu Mar 4 07:32:57 PST 2010


On Wed, Mar 3, 2010 at 6:25 AM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
> On Tue, Mar 2, 2010 at 9:49 PM, Adam Goode <adam at spicenitz.org> wrote:
>>> Some advantages:
>>> * SVN or Mercurial for project code
>>>  * web interface (google custom, not ViewCVS)
>>> * Project wiki with a subset of MoinMoin markup (would make copying
>>> existing wiki relatively easy)
>>> * Integrated issue tracker
>
> I don't find the advantages list here to be very compelling. The only
> real plus is the issue tracker. We already have something better than
> or equal to the other advantages. AFAICS, the main point is just the
> relief of administrative burden.

This was meant to be some advantages of Google (Code/Groups/Sites/...)
in particular, not general advantages of moving away from a
self-hosted mlton.org.  The advantage of moving away is the relief of
admin overhead.

>>> Some disadvantages:
>>> * Possible code license issue; Google Code requires choosing one of a
>>> small number of open source licenses, including MIT License and New
>>> BSD License
>>> * Project membership iff code access and wiki access; i.e., no
>>> fine-grain permissions.  [Probably not a major issue; few wiki edits
>>> from non developers.]
>>> * Project wiki loses some of our useful MoinMoin extensions (links to
>>> SVN revisions/files, (good) SML code formatting, SML code pulled from
>>> SVN, ...)
>>> * Dispersal of URLs: mlton.org for mailing lists, mlton.org for one
>>> site, mlton.googlecode.com/ for source repository,
>>> code.google.com/p/mlton for project wiki, issue tracker, etc.
>
> Aside from the license issue, all these other disadvantages could be
> lumped under 'loss of control'. By going with a large-scale project
> website it's a 'take it or leave it' proposition. We only get the
> features they offer. I imagine that as time moves on, other things
> will be added to this list.

Agreed that moving to a project-hosting site means only having the
features they offer, and with it a limited loss of control.  However,
I disagree with the conclusion that the list is likely to grow.
Indeed, I noted that SourceForge.net added a lot of features over the
last few years.  Also, a project-hosting site is likely to support
(and add support for) features that are relevant to development
projects.

> So I think the main point is: administrative burden vs. ability to
> customize the site.

Agreed; but, remember, "the site" is more than just the www presence.

> Which part of the administration is the most work? Keeping the system
> up-to-date or dealing with issues or something else?

I think all of these are parts of the administration overhead.
Keeping the system up-to-date is not just a matter of updating with
distribution-provided security patches.  As you noted once before,
mlton.org is running Debian 3.1, with no more security or feature
updates.  Updating to something newer almost certainly means that
mailman, apache, svn, MoinMoin, ... will also be updated.  Who knows
how smoothly any of those upgrades would be.

Again, the advantage of a project-hosting site is that (presumably)
any service upgrades will be thoroughly tested, since they will impact
many projects simultaneously.

> If the
> up-to-dateness is a problem, moving to a shared server (non VPS)
> relieves that issue (I offered this before).

I don't see how a shared server is better than a project-hosting site.
 Indeed, in many situations it could be worse.  On a shared server, we
would only have the features installed (and supported) by the server,
which may or may not be geared towards a development project.  Being
hosted as a pro bono service probably means being a low-priority for
support, a prime candidate for budget cuts, etc.  [Yes, a
project-hosting service could disappear at any time, but it seems less
likely.]

> The number of issues we
> get with a googlecode solution may be reduced, but the remaining
> issues might be largely unsolvable.

What do you see as an unsolvable issue?

> All in all, though: rather than invest time in moving mlton.org, how's
> about a new release? :D

Making (slow) progress.



More information about the MLton mailing list