I'll snip most of Rusty's responses, since I've commented earlier in the thread.<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="http://ccan-repo.org">ccan-repo.org</a> is the one I like most so far, but I'd love to find someone<br>near Ohio who can chase down ccan.org...</blockquote><div><br>This is probably a good idea, OR we can try to get
<a href="http://ccan.com">ccan.com</a> first, before we spook he <a href="http://ccan.org">ccan.org</a> owners...<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree: two licenses is already one too many. But there is existing code<br>which is GPL which would be useful (talloc springs to mind), and so GPL and a<br>weaker license makes sense. (BSD no advertising can be mixed with GPL no
<br>problems).</blockquote><div><br>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.
<br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > 5) Uploading, automated testing, etc. No idea here, plan to steal as
<br>> > much of CPAN as possible for this.<br>><br>> I think we need to use something bzr or darcs where people can send<br>> patches to the maintainer. These need to be tested before added for<br>> inclusion into the repo. There need to be some requirements before a
<br>> module goes in (like tests, license etc).<br><br>The repo itself will probably be bzr (since that's the one I haven't used<br>yet :), but it will need to be available through multiple means, and<br>similarly submission should be possible by "upload a tarball".
<br><br>We have to balance requirements with ease of contributing. I'd prefer to<br>accept anything but then grade them (automatically). I'm hoping that Adam<br>Kennedy will weigh in here...</blockquote><div><br>
I've mentioned that tarball should be the primary unit of code.<br><br>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.
<br><br>The reason this is the case is that we let people upload (almost) literally anything they want.<br><br>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.
<br><br>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.<br><br>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.
<br><br>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.<br><br>CPAN doesn't even check that uploaded code has a license. We react to observations of illegal or unlicensed code after the event.
<br><br>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.
<br><br>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.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > 7) Automatic downloading, testing, checking for updates, and dependency
<br>> > tracking. This would be nice, particularly handling namespacization<br>> > and detecting local mods.<br>><br>> Again bzr of darcs can automatically take care of the updating,<br>> dependency tracking and detecting local mods.
<br><br>I'm not so sure. I don't think most people are going to grab the entire repo.<br>They want the hash table routine, for example (and, by implication, anything<br>else in ccan that needs). I think there are several use cases:
<br><br>1) Junkcode-style:<br> grab a module, copy it into my source, never look back.<br>2) New project:<br> grab a module, drop it under ccan/<modulename>. May update later.<br>3) Large existing project:<br>
grab a module, drop it under ccan/<modulename>, namespacize.<br> May update later.<br><br>While it'd be nice to ship helpers like "ccan-grab" and "ccan-update", I think<br>that "download a tarball" is going to be the most universal method; and we
<br>can generate tarballs automatically containing all the dependencies.</blockquote></div><br>"minicpan" is one of our most popular tools.<br><br>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.
<br><br>TONS of Perl developers keep minicpan repositories (currently at about 750meg) on their laptops for hacking on planes and so on.<br><br>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.
<br><br>