[mercury-users] Mercury Anarchive proposal

[Julian Fondren]

On 2/22/07, Ondrej Bojar <bojar at csse.unimelb.edu.au> wrote:
> Manarchive will be a repository for generally useful routines, like c?an's
> are
> for Perl, TeX, R-Project and others. I am not too ambitious at this point.

The Mogul Archive also seems somewhat successful:
    http://www.mozart-oz.org/mogul

> - has the Manarchive to adopt a specific copyright policy to be useful for
>    you?

I've seen it asserted several times by sensible people that the
'GPL or Artistic' licensing of the whole of CPAN makes it much
easier for them to simply look for and then use worthwhile
modules.

I recommend only that you pick the LGPL over the GPL, if you
decide on one license, due to the GPL's viral nature.

>    I'm not good at picking one of the ready-made licences, all I want is
>    that my credit is recognized and kept in comments. I do not mind if the
> code
>    I'd contribute would be used in for-profit systems.

The Artistic license of the Perl community essentially means this.

>    I sort of prefer keeping the main repository on disks I have nearly
> physical
>    access to, but regular 'svnadmin dump' can solve this.

The Erlang community has 'jungerl', a 'jungle of Erlang code',
as a source code repository with easy addition of maintainers,
as with your idea, and I think it has not been nearly as
successful as much simpler schemes in e.g. the Ruby community,
which originally had a 'Ruby Application Archive' that didn't
even host the projects it listed and linked to.

I think the one-true-ultimate-best solution would be a site that
hosted SVN repositories that also automatically built and listed
packages from blessed versions of those application-specific
repositories, using .spec -type files kept in those repositories.
e.g., foo.spec would tell the lister about categories, manifests,
and such, and a .release file, when updated, would trigger a new
release of the repository as a package.

But anything you come up with should be fine.

>           # ideally, the pre-commit validation would not allow committing if
>           # any package fails some of the tests after your change that were
>           # successful before your change

Why is this ideal?  The most amazingly test-driven project I've
seen, the Perl6-in-Haskell Pugs project, -needs- failing tests.
If no tests fail, then the project is done!  (Or the tests don't
actually cover the whole of Perl6, or something went horribly
wrong and a mentality of tests-must-always-pass has corrupted
the system).

>      It must be easy for a Manarchive package to depend on other Manarchive
>      packages (at the current Manarchive revision; no version spaghetti,
>      please)

The alternative to 'version spaghetti' is: a constant mild
earthquake as one project incompatibly updates and N other
projects no longer build.  Both of these alternatives require
maintenance to clean things up, but when 'version spaghetti'
gets bit-rotten, things just get a bit ugly.  When your
preference gets bit-rotten, even a little bit, everything
is exploded and useless.

> 2. People are kindly asked to stick to coding style of the package they are
> modifying. Bringing your own package, you can bring your own style.

They are kindly asked to do something you intend to enforce? :-)

Cheers,
Julian
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------