[ccan] CCAN status update

[Adam Kennedy]

Rusty Russell wrote:
> On Thursday 20 March 2008 10:54:37 Adam Kennedy wrote:
>   
>> One of the biggest lessons from CPAN is that it is essential that you
>> maintain clear separation from the release environment and the author's
>> development environment.
>>
>> A release should be specific and intentional, and not simply be
>> "whatever is currently in version control".
>>
>> So I suggest we keep releases to just tarballs.
>>     
>
> So, we're talking about individual modules having releases, rather than 
> a "CCAN" release?  Even so, I'd prefer to keep a "release" tree/branch and 
> have people commit to that.
>   
Correct.

The single most common failure made by library developers in every 
language is that they treat their entire collection of modules as a 
single entity.

The result isn't a repository, it's a "toolkit" (for example, the 
gazillion similar but different JavaScript "toolkits".

This leads inevitably to bloat and stagnation.

The bioperl project, a giant bloated collection of "everything related 
to Perl and computational biology" has been stuck at 1.4 since 2003. The 
project got so big, they can't change it all at once.
> I pretty much assumed that most developers (ie ones that do more than throw in 
> code and walk away) will hold the whole repo.  But maybe that's just me.
>   
Unfortunately, that doesn't scale very far... the "entire" CPAN 
repository is around 1 gigabyte compressed.

So that would be something like a 10-20 gig checkout, uncompressed, with 
god only knows how many directories and files.
>   
>>>> Mostly, I hate it because I can't see a simple way to refactor the
>>>> layout of the repository easily by anyone other than you :)
>>>>         
>>> I'm happy to change to mercurial if you prefer that.  I don't know what
>>> the Windows support is like.  Any ideas?
>>>       
>> To be honest, I was thinking more along the lines of bog standard svn
>> for the core CCAN repository.
>>     
>
> Erk, I'd prefer to have something more sophisticated, but standard-tool 
> friendly.  At least mercurial has a 'download .tar.gz' button which takes 
> care of challenged platforms.  We should certainly have the same thing for 
> ccan.
>   
This somewhat depends on what exactly we're talking about as the 
"repository".

I am mostly referring to a version control repo that will hold the 
website content, the indexer and mirroring and etc code, and so on.

The master CCAN repository should be a simple FTP-mirrorable directory 
structure containing the release tarballs, with a database of some sort 
to hold all the metadata and master indexes.
>   
>> Where each individual author, or collection of authors, choose to store
>> their modules should not need to be important.
>>     
>
> It's a good point, but I'd like to do this without dropping back to svn on the 
> main server.
As I understand decentralized version control (bzr, mercurial, etc) 
there's no way I can commit to the project?

I have to send every single change to you by email as a patch file?

So lets assume we hit the first scaling threshold of 100 modules and 
20-50 developers, exactly how many patch files is that one central 
person going to need to manage a day?

Or am I seeing this wrong?

Adam K