Mozart tools development

[Torsten Anders]

Dear all,

In this email I come back to the development of tools like ozh (a 
javadoc-like documentation generator, see 
http://www.mozart-oz.org/mogul/doc/franzen/ozh/index.html). However, I 
am not talking about this specific application only. Probably many of 
us develop their personal library of tools for daily jobs. For example, 
there is OzUnit (unit testing for Oz by Juergen Stuber), OzServer 
(making the Oz compiler available for other apps and languages via a 
socket), Prototyper (I am currently working on a tiny interactive Oz 
tutorial based on the QTk prototyper) and so forth.

I want to kick off a community project for developing/maintaining 
Mozart development tools (I volunteer for administrating this thing). I 
feel that such tools are best developed by the people who actually use 
it -- which is potentially every Oz/Mozart user. I would very much like 
to encourage the "drive-by" coder, who just provides 1-2 patches to 
scratch a personal itch. I envision a pragmatic wiki-style development 
of Mozart development tools, where everybody can contribute with a 
minimum amount of hassle.

This is the workflow I have in mind. There will be some main repository 
at some project server with the code for Mozart tool X. Joe Hacker 
downloads X and implicitly creates a local branch of it. Please note 
that Joe is not registered in any way. Joe hacks freely the downloaded 
code and every now and then commits to his local branch. He can also 
synchronise his local branch with the main branch to receive any 
patches to X done by somebody else. Now, when Joe is done and fixed a 
specific bug or added some new feature, he merges his branch (or parts 
of it) directly into the main branch -- still without being registered. 
However, he must leave his full name and email with his patches, and is 
expects to provide test cases. Optionally, every newly added patch (or 
merged branch) launches some unit test suit -- in case of a fail the 
patch is automatically undone. A project webpage would detail this 
workflow.

Here is a proposal how this project could operate technically. The 
repository is based on darcs (http://darcs.net/) and a darcs-server 
(http://www.equational.org/darcs-server/) is running on the project 
server. This means that there must be darcs installed on the server 
(can be a problem), together with a Perl installation (unlikely a 
problem), and the server must either support CGI scripts, or has SSH 
access (SSH would be configured such that only the darcs-server can be 
executed by everyone). Of course, every developer has to install darcs 
as well.

I would really like to allow EVERYONE access to the main repository. I 
don't think that vandalism can be an issue here: who will bother to set 
up darcs and change some code repository which is not visited from 
anyone outside the Oz community? Besides, everybody will see the 
changes and can undo them. If indeed this freedom turns out to be 
problematic, then it is always easy to change the rules and restrict 
access to a few which are allowed to commit patches send by email or to 
merge branches published, for example, on the project server or 
anywhere else..

Now, what do you think about this idea?

Boriss, could such a project run on gforge.info.ucl.ac.be? Does 
gforge.info.ucl.ac.be allow for the installation of tools like darcs 
(e.g., sourceforge.net does not..)?

Thank you!

Best,
Torsten

--
Torsten Anders
Sonic Arts Research Centre • Queen's University Belfast
Frankstr. 49 • D-50996 Köln
Tel: +49-221-3980750
http://strasheela.sourceforge.net
http://www.torsten-anders.de