[ccan] CCAN status update

[Adam Kennedy]

Rusty Russell wrote:
> On Tuesday 18 March 2008 23:10:17 Adam Kennedy wrote:
>   
>> Since we've been accepted as a mentor org, I've been looking more into
>> the current repo.
>>     
>
> Bwahah, my plan is working!
>
>   
>> One thing we really need is some intro docs on how to get started, which
>> I'll admit I need more than other people since I'm not a C native. It
>> also would help me understand the workflow you are currently using.
>>     
>
> Yes.  Currently my workflow looks like this (note the nice recursion as I 
> create submodules):
>
> create_module := write_module test_module checkin_module
> write_module := [create_module]* [enhance_module]* WRITE-C-CODE
> test_module := 'make test-<modname>'
> enhance_module := WRITE-C-CODE test_module
> check_in := 'bzr checkin'
>
>   
>> It's probably also time to look at doing a repository refactor as well,
>> to start to conceptually separate a few things we've currently got
>> munged together.
>>
>> For example, we currently don't separate the repository state of
>> packages from the release state.
>>
>> That's fine for now, but it's something we probably need to look at
>> fairly soon.
>>     
>
> Yes, I'm just not sure how we want to do this.  I like the idea of a flow like 
> the following:
>
> new code comes in (bzr checkin or tarball)
> -> automatic evaluation (does it have _info, testcases, other ccan-lint 
> checks, etc)
> -> place in appropriate spot (eg. junkcode, repo, core?)
>
> updated code comes in (bzr checkin)
> -> automatic evaluation and regression testing.  Stop if fails.
> -> Non-core: commit.
> -> Core: commit to testing branch.  After some delay w/ no bug reports, move
>    to main branch.
>
> Of course, the way we divide the modules is not necessarily reflected in the 
> repository.
>   
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.

This also helps with continuity of maintainership, as development 
environments necesarily vary from developer to developer, and if a new 
author takes over a package, they should only have to unpack the most 
recent tarball into their repository and be done.

>   
>> I have to say I'm also not a huge fan of bzr either (I know you wanted
>> to try it out because it was a version control you hadn't tried yet) :)
>>
>> Mostly, that's because I hate 1. Email 2. Patch files 3. Not having lots
>> of people able to commit to trunk 4. Not having a decent Win32 gui that
>> I can find.
>>     
>
> Hmm, it's not entirely clear how to do that with bzr.  I assumed it was like 
> mercurial (where you can either bundle together the changes and send them any 
> way you want, or give you your ssh key and I can give you commit access to a 
> particular repo).
>
> I'll test this out...
>   
>> 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.

Where each individual author, or collection of authors, choose to store 
their modules should not need to be important.

Adam K