[ccan] CCAN issues

[Adam Kennedy]

I'll snip most of Rusty's responses, since I've commented earlier in the
thread.

    ccan-repo.org is the one I like most so far, but I'd love to find
> someone
> near Ohio who can chase down ccan.org...


This is probably a good idea, OR we can try to get ccan.com first, before we
spook he ccan.org owners...

I agree: two licenses is already one too many.  But there is existing code
> which is GPL which would be useful (talloc springs to mind), and so GPL
> and a
> weaker license makes sense.  (BSD no advertising can be mixed with GPL no
> problems).


As mentioned, one of the strongest network effects is that people start
converting existing code to become "CCAN-compliant packages" and in many
cases may switch to CCAN as the primary distribution method, especially if
you can create things like CCAN to debian auto-convertors and such.

We should try to be as flexible as we can about licenses, within the scope
of the legal problems created by license mixing. If we HAVE to dictate a
standard license, so be it. But that should be an absolute last resort.

> > 5) Uploading, automated testing, etc.  No idea here, plan to steal as
> > > much of CPAN as possible for this.
> >
> > I think we need to use something bzr or darcs where people can send
> > patches to the maintainer. These need to be tested before added for
> > inclusion into the repo. There need to be some requirements before a
> > module goes in (like tests, license etc).
>
> The repo itself will probably be bzr (since that's the one I haven't used
> yet :), but it will need to be available through multiple means, and
> similarly submission should be possible by "upload a tarball".
>
> We have to balance requirements with ease of contributing.  I'd prefer to
> accept anything but then grade them (automatically).  I'm hoping that Adam
> Kennedy will weigh in here...


I've mentioned that tarball should be the primary unit of code.

I'll add to this a cultural point. One of the most noted things about the
CPAN is that it has both enormous amounts of useful code, but just as
enormous amounts of crap code in it.

The reason this is the case is that we let people upload (almost) literally
anything they want.

The upload concept is that each author gets a "home directory" within the
master CPAN filesystem tree, into which they can put anything they like.

Then the indexer will look at the stuff they upload, and try to work out if
any of it looks like a "package", in which case it will open it up, read the
metadata, index it and so on.

It is very important that we keep the barrier to entry as low as we can,
because we are dealing primarily with volunteers and if you put barriers in
the way they simply won't upload.

And a lot of modules that started off as bad code in the initial releases
gets a lot better over time, particularly as it gets taken over by other
authors down the track.

CPAN doesn't even check that uploaded code has a license. We react to
observations of illegal or unlicensed code after the event.

People who want "quality control" generally only see the modern CPAN, and
think of the problem in terms of needing to somehow "protect" the
repository. What they generally miss, and the reason why we admins resist
these efforts, is that we need code from people far more than they need us,
otherwise the CPAN simply wouldn't exist in it's current form.

Now, if I had the option to apply any form of quality control to CPAN,
personally I would check ONLY that any upload that we are going to treat as
a "CCAN Package" and provide in the index has a license of any sort that we
recognize and know we can distribute, because there are most likely legal
issues for us providing a distribution network for this code.

> > 7) Automatic downloading, testing, checking for updates, and dependency
> > >    tracking.  This would be nice, particularly handling
> namespacization
> > > and detecting local mods.
> >
> > Again bzr of darcs can automatically take care of the updating,
> > dependency tracking and detecting local mods.
>
> I'm not so sure.  I don't think most people are going to grab the entire
> repo.
> They want the hash table routine, for example (and, by implication,
> anything
> else in ccan that needs).  I think there are several use cases:
>
> 1) Junkcode-style:
>     grab a module, copy it into my source, never look back.
> 2) New project:
>     grab a module, drop it under ccan/<modulename>.  May update later.
> 3) Large existing project:
>     grab a module, drop it under ccan/<modulename>, namespacize.
>     May update later.
>
> While it'd be nice to ship helpers like "ccan-grab" and "ccan-update", I
> think
> that "download a tarball" is going to be the most universal method; and we
> can generate tarballs automatically containing all the dependencies.


"minicpan" is one of our most popular tools.

It derives a partial mirror from a full CPAN mirror that contains every
packaged with an entry in the index. That is, it keeps the most current
tarball for any package that you might want to install.

TONS of Perl developers keep minicpan repositories (currently at about
750meg) on their laptops for hacking on planes and so on.

It's also very common to burn them onto a CD or copy onto a 1gig flash
drive, so that full CPAN installations can be done in highly secure
environments with firewalled or completely isolated networks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/ccan/attachments/20071220/8963937a/attachment.htm>