[ccan] CCAN issues

[Adam Kennedy]

My apologies for the delayed mails, I'm having some troubles sending "From:
adamk at cpan.org", so I've switched over to a pure gmail account for now.

I'll make some quick responses at the moment, but I'd just note that we need
to be VERY careful what underlying choices we make for what the CCAN
becomes. Scope and constraints make or break whether this stuff works in the
long run.

On 18/12/2007, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> OK, so I promise I'll put up a bzr repo sometime soon, but meanwhile
> here's a
> list of thoughts on open issues in no order:
>
> 1) Domain name.  ccan.org would be ideal: seems to point to a generic ISP
>    page, whois says Community Care Ambulance Network in Ohio, which seems
>    legit at first glance.  ccan.com seems to be for sale by a squatter,
>    perhaps we could do some deal where we buy ccan.com for the ambos and
> get
>    ccan.org?


I'd say do whatever we can to get the best possible name, it makes a huge
difference.

The JSAN (JavaScript Archive Network) ended up going with openjsan.org,
although after putting in some time I did have an option to get jsan.net,
which would have been preferable but was overruled because getting a domain
was always "done".

Lets find someone from Chicago and make contact with those guys.

Or perhaps we can use ccan.com? or ccan.net?

Using a domain for any specific country it out, as these projects are always
global in nature.

2) Namespacization.  If someone can't use (say) container_of because their
>    existing project uses that name, it'd be nice to rename it to
>    ccan_container_of.  Of course, this means any other ccan modules which
> use
>    this need changing too.
>
>    I thought about making the ccan_ versions canonical and providing
> macros
>    to map to the normal names, but it breaks the golden rule:
>
>         This code must not be ugly.
>
>    So I chose the harder road of supplying a C program to actually rewrite
> the
>    module and anything which depends on it.  Not quite finished yet, but
> it
>    has the merit of placing the burden of ugliness where it belongs.


This part is tricky, and I'm not sure there's much I can do to contribute,
since I'm not experienced in this area. But I'll talk more a bit later about
these sorts of issues (I'm up to my eyes in Perl 5.10 release stuff for
another few days).

3) Minimum compiler requirements.  Seems like Microsoft's C compiler doesn't
>    do vararg macros, let alone any other C99 stuff.  This makes it
> impossible
>    to have nice code for some things, so for the moment I'm still sticking
>    with my intention of requiring (most of) C99, and Windows coders will
> have
>    to hope they catch up, or we do some horrible mangling at the user end
>    (like namespacization).


As a general rule, dealing with commercial programs is hell.

Strawberry Perl demonstrates a precedent for using MinGW and (in our case,
for some specific legacy reasons) dmake to build various stuff.

4) Licensing: so far I'm restricting it to with BSD no advertising, or
> GPLv2+.
>    More than that makes life too tricky for people wanting to use the
> code.


This is going to be one of the more complex and unique elements of this
project, because we haven't hit it with either Perl or JavaScript, we may
need some help from legal counsel.

5) Uploading, automated testing, etc.  No idea here, plan to steal as much
> of
>    CPAN as possible for this.


These are non-issues for now. The various elements of the CPAN "cloud" of
services are written and owned independently and were created after and
around the core.

In particular, you should completely ignore things like documentation
websites, automated testing and quality control and so on for now.

6) I have documentation-extraction code, but it doesn't do any xml-style
> guff
>    (the Linux kernel's system on which this is loosely based is perl
> based, so
>    maybe we should just steal that for the documentation, as it does
> various
>    different output forms).


The only thing I'd not on this topic is the Perl code this part completely
right.

By convention, the docs don't just show function/method details, they also
have free-form description sections, allow samples in synopsis sections, and
so on.

They act much more like in-line man pages than API docs, and this has worked
enormously well.

7) Automatic downloading, testing, checking for updates, and dependency
>    tracking.  This would be nice, particularly handling namespacization
> and
>    detecting local mods.


Ignore automatic downloading, ignore testing, updates and dependency
tracking. We aren't ready for that yet.

The first two major elements we need to define is

1. The toolchain and methodologies on a per-package basis.

(Issues like libtap and which compilers we support belong)

2. The definitions for what the actual "products" the CCAN provides are.

(Issues like cut-paste vs code munging vs libfoo distribution).

Once we have a rough handle on what a "CCAN package" is, and how it is
structured and installed, the rest is either a) Irrelevant or b) Unscopable.

Solving the wrong problems too early is a common fault of some of the worse
repositories.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/ccan/attachments/20071220/a2335df8/attachment.htm>