[mercury-users] Mercury Anarchive proposal

[Ondrej Bojar]

Tom Breton (Tehom) wrote:
> No strong constraints here, but you might consider GPL because it's
> already well known and understood.

My crude knowledge says: GPL is 'sticky'. If your project contains anything 
GPL'd, you are not allowed to give anyone your executable, unless you give out 
our source, too. LGPL is a better option here, but it might have an 
unacceptable condition for someone. (I do not know about such a condition, but 
I do not know the details.)

> Sourceforge is fine for me, but I wonder if it suits your goal. 
> Contributors on sourceforge have to be developers, and all developers can
> edit all the code.  It also expects to work thru CVS, which is really nice
> for branching and merging development but seems unneeded and complex for a
> repository of contributions.

The rationale behind CVS/SVN (roughly equivalent systems) is to make the life 
easier for the contributors themselves. For example, once I've contributed 
something, I will *delete* my personal repository of the package and will 
continue development only on the Manarchive repository. And I do want to have 
some version control working. I do not use branches at all, but I might start, 
if I were to modify more packages (of my own or other people's).

The rationale behind all contributors being equal (readers only do not have to 
get an account at sf, do they?) is this: if you contributed something, you 
know how much time does it take. You surely do not want to ruin someone else's 
work. So all changes you might wish to make to someone else's code will be 
limited to bug fixes. For feature modifications, please always contact the 
author of the package. I admit that this policy should be stressed to everyone 
who'd like to join. It is easy to ask the people, because sf's project admins 
manually add new contributors.

>>      svn checkout
>>      make  # to compile all the parts that have prerequisities satisfied
>>            # (some of the packages might depend on some libraries
>>            # installed; only users wanting such packages should be forced
>>            # to satisfy the prerequisities)
>>      mmc --make \
>>          `manarchive-config --print-mmc-flags --package X --package Y` \
>>          myproject
>>            # to link against packages X and Y (if they were successfully
>> made)
> 
> I'm familiar with CVS, not SVN, but doesn't "svn checkout" suck in the
> entire repository?  Is that what you want?  It seems contrary to what
> you're saying.

You can ask CVS/SVN to suck just a subdirectory, but this was not what I wanted.

Not expecting too many packages to emerge very quickly, I felt it's not too 
wasteful to always download the source code of all the packages. Possibly the 
compilation should be restricted to those you need.

I also do not have the time to implement a full-featured download and 
dependencies manager. Having all packages as subdirectories in a single 
'project' solves this very easily.

> The trick would be to convince mmc or mmake to go looking on "Manarchive"
> for modules it doesn't find locally.  Even trickier, convince it to do so
> without introducing new problems.

That is precisely the reason I do not wish mmc to know about Manarchive at 
all. (At least until more than half of the glory moves to Manarchive and 
Mercury would want to get the lost glory back. ;-)

O.

-- 
Ondrej Bojar (mailto:obo at cuni.cz / bojar at ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------