[ccan] What do we mean by "judging code"

[Rusty Russell]

On Thursday 20 March 2008 11:46:32 you wrote:
> One of the principles from the CPAN that has been extremely positive is
> the idea of a low barrier to entry.

Yes, I'm completely with Adam here, BTW, only even more extreme on accepting 
stuff.

I'd like people to be able to upload a tarball or a single file.  If it 
doesn't meet certain minima, it gets placed in "junkcode"; it's there if 
people want to take it and/or improve it, but it's understood that it's just 
been dumped there.

This is why I consider what I've been calling ccanlint as important.  In 
summary mode does a kwalitee-style report, which we can tie into a web 
interface to give people some inking of the state of the package (plus vanity 
scoring!).  But ideally I'd like it to also perform as an interactive 
tutorial on ccan-izing and improving code, eg:

$ ccanlint myproj
No _info.c found.
  _info.c is the small program which contains information about the code.  
Create template for you? [Y/n] y
$ vi myproj/_info.c (edit out #error lines to replace with real things).
$ ccanlint myproj
_info.c does not have docbook style comment describing the module.
   CCAN uses specially-marked comments for usage documentation: the comments 
in _info.c are the documentation for the package as a whole.
Add documentation template for you [Y/n] y
$ ccanlint myproj
myproj.h does not exist
   CCAN modules conventionally have a header of same name as the module.  
Perhaps your should rename one of the header files, or the directory (ie. 
module name) to something appropriate.

Writing this program is, of course, an infinite and ongoing task.  It should 
run tests, measure coverage, turn off all the HAVE_ macro combinations, check 
API documentation extracts correctly, check that namespacize works properly, 
check that it specifies all its dependencies, and that it needs all the 
dependencies it specifies, etc, etc.

Thoughts?
Rusty.