Mozart development

[Filip Konvička]

>>> An important but somewhat hard question is this: how can the 
>>> development of individual Oz contributions be maintained by the 
>>> community? In particular, how are orphaned Mogul packages 
>>> maintained? For example, ozh 
>>> (http://www.mozart-oz.org/mogul/info/franzen/ozh.html) still 
>>> supports only Mozart 1.2.5. Filip Konvicka provided a patch for 
>>> 1.3.* 
>>> (http://lists.gforge.info.ucl.ac.be/pipermail/mozart-users/2006/008016.html), 
>>> but that patch hasn't been merged into the ozh Mogul package.
>> I've been thinking of this too. I tried to contact the author of ozh 
>> but I think he is not reachable at the original address anymore, so I 
>> thought of creating a clone contribution "ozh2". What do you think of 
>> this?
>
> I think this is a general problem. Starting an ozh2 where you are the 
> author is quasi a 'hack' which only solves an immediate need. Taking 
> over maintainance of ozh would be another solution. But both options 
> are probably too much for an occasional patch.
The problem is that the MOGUL librarian downloads the library from the 
original author's website every night. So without being able to reach 
him, we have no chance of maintaining anything.
> Would it perhaps be a good idea to move some or even all Mogul 
> packages over to gforge.info.ucl.ac.be and allow registered developers 
> to fix things? To avoid any irritation, we may introduce a distinction 
> between individually maintained Mogul packages (the only approach so 
> far), and packages maintained by the community. The author may decide 
> whether she/he permits community maintenance. The problem remains for 
> packages whose author does not respond. In that case, we may consider 
> starting a community branch (e.g. ozh2).
Good idea. With this approach, we might be able to have (almost) 
everything in the public repository, + we would not be forced to change 
the way the librarian works. That would mean asking every contributor to 
send the current source code (incl. makefiles etc.) to some admin, 
configuring svn for this, creating web space for the packages and 
redirecting the packages' URLs to gforge. I'm not sure about the 
build/upload process, though.

I'm also not sure about which contributions we need to have in the svn. 
Maybe the transition could be demand-driven, which would perhaps mean 
that just a few contributions need to be migrated. Does anyone have the 
idea which contributions are "popular" ? :-) The reason why I mention 
this is that some contribs might be harder to maintain/build than others...

Cheers,
Filip