Dear hackers,
over the last months, the Mozart project has been moving more and more
towards a publically developed, open project. The centre of activities has
clearly moved to Belgium currently, with Boris and Yves preparing a
long-awaited new release.
The current development architecture, however, doesn't reflect these changes
yet. Everything is still hosted here in Saarbrücken: the web pages, the
CVS, the mailing lists. We believe that this is not optimal for both you as
the active developers and for us as administrators. Ideally, control over
the infrastructure should be in the hands of those who use it.
On the one hand, for any changes (new logins, bad file permissions, group
membership etc.) you have to ask us for help. On the other hand, we have to
maintain quite some infrastructure, make sure no updates on our side break
any of the Mozart related services, and provide support for all technical
problems.
I want to start a discussion on how this situation can be changed, I hope,
to the better for all of us. In the end, this discussion should result in a
couple of MEPs that regulate how Mozart can be developed in an open source
style - i.e., who is responsible for accounts, CVS access, the web pages,
etc.
Our concrete proposal consists of four steps:
Step 1 - The news server.
We would like to switch off our news server, as it is used for mirroring
mailing lists only. Our proposal would be to use a free service like
gmane.org for mirroring. As this is not such a big issue, we want to do
that in the very near future if no one objects.
Step 2 - The CVS.
The source code repository should be moved. I would suggest to use a service
like sourceforge or savannah, and to maybe move to subversion (just
personal taste, though). That way, the developers (or the board) can give
write access to the CVS as needed, and you get a bugtracker and release
management system on top of it.
Step 3 - Mail.
Currently, we are hosting two services: email addresses for developers, and
the mailing lists. The mailing lists could be hosted at sourceforge or
savannah, too.
For the mail aliases for developers, it would be enough to register the MX
record for the mozart-oz.org domain somewhere where you can easily define
forwarders (e.g. for gecode.org, we've used namecheap.com).
Step 4 - The web pages.
The Mozart web site, as nice as it may look on the surface, is a weird
mixture of Mozart scripts that we don't have any source code of, php, perl
hacks and some html. It is a nightmare to maintain, and we were more than
lucky that it survived our server migration last year. The bugtracker,
jitterbug, is a discontinued project - no updates, no support.
All in all, the web site will need the most work, definitively.
Of course, we will try to help out where we can during the transition - and
until an optimal solution is found, we will fully continue hosting and
support for Mozart. I am sure, in the end this will push Mozart much more
in the direction of a community product.
Cheers,
Guido
--
Guido Tack
Programming Systems Lab, Saarland University, Germany
http://www.ps.uni-sb.de/~tack
_________________________________________________________________________________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
