[ccan] CCAN status update

[Rusty Russell]

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.

Of course I want the "one-click" download to grab a tarball of a package (and 
all its deps).  There's no reason that we can't have an input tarball method 
for new releases, too: we need it for new packages anyway.

That means you can just grab the release tarball, work with that, then upload 
your new version, and completely ignore the repo if you want.

> 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 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.

> >> 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.

> 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.

Cheers,
Rusty.