Hi: On Tue, May 12, 2009 at 7:40 AM, David Cantrell <[email protected]> wrote: > On Mon, May 11, 2009 at 08:07:36PM +0100, Paul LeoNerd Evans wrote: > >> I was recently pointed in the direction of my kwalitee tests: >> http://cpants.perl.org/author/PEVANS >> They all fail for not having a README file or a LICENSE. > > After a few months, I came to the conclusion that the CPANTS game isn't > worth bothering with. My time is better spent writing code, improving > my test coverage, improving my portability, and drinking beer than it is > with silly things like that.
While I agree that you shouldn't take those metrics *too* seriously, I do think that they have a place and that they are useful in helping ensure overall software quality in practise (and not just kwalitee as promised). And actually looking at your ratings (http://cpants.perl.org/author/DCANTRELL) it looks like you're generating META.yml using an old Module::Build or by hand. In either case, you're missing a license reference in META.yml, which might not matter to you, but it does save some time for those interested in programmatically determining what license terms you set. Obviously nothing to bother with new releases about, but maybe something to consider for future bug fixes. I think a lot of the metrics (that are not the experimental ones) are covered by good package maintainers anyway. Certainly, the fact that your packages pass the majority of tests despite your thinking that Kwalitee is of little importance, is a good sign. It means that these are often best practices that module maintainers are using anyway, and helps enforce them particularly for newer developers. It's a convenient tool. Not the be-all and end-all of course, but useful nonetheless. Possibly a lot of the things mentioned by the Kwalitee reporter are wishlist issues and not real bugs, but y'know, if you have some free time and you're bored... :-) > >> I was wondering, since I have e.g. the following Build.PL: >> >> module_name => 'IO::Async', >> ... >> license => 'perl', >> >> surely Module::Build ought to be able to automatically satisfy both >> these conditions? >> >> * Take the module given by module_name (or some other named one), run it >> through pod2txt >README > > I don't think that's what README is for. There's no sense in > duplicating the documentation. README is where you put the instructions > on how to build and install your software. I have to say I agree with this. I myself just do pod2txt like that. Maybe installation stuff should be in a separate file, ie, INSTALLATION. Generally my READMEs are (admittedly) just a way to satisfy the needs of CPANTS. > >> * Look up the named license from a standard set of default ones and >> print it to >LICENSE >> Are either of those doable automatically? > > That could be a reasonable thing to do, but even then you still have > problems with how to represent dual-licenced code. Indeed. Personally I just copy what I mean to the file itself. I think most of us will have one or two preferred licenses (I'm thinking of GPL and MIT/BSD) for all(-ish) our code, so it's not a huge problem to do so manually. One thing LICENSE files are helpful for is to provide clarity for downstream people packaging modules, ie, Debian and Fedora. All too often, module authors completely forget things like a Copyright year (in most boilerplate license reference texts) and to specify which version specifically. > > -- > David Cantrell | A machine for turning tea into grumpiness > > All praise the Sun God > For He is a Fun God > Ra Ra Ra! >
