Randy Stauner

We could attempt to add that data (license_file) to the release document... then we could link straight to the file without adding another api request. Another option would be to...

I had trouble finding this other comment (https://github.com/CPAN-API/cpan-api/issues/373#issuecomment-69439358) so I'm quoting it here to collect the comments in one place: > The documentation for "indexed" > says "include in the...

At first glance it looks like this is happening because the pod is in a separate file. Seems like it would be good to copy the description from the pod...

It may also be worth noting that the "provides" section in the release appears to be correct(ly limited): ``` { "resources" : { "repository" : { "url" : "http://github.com/mvgrimes/perl-tidy-sweetened" },...

no, the "metadata" key comes from the META file (and is therefore similar to the spec). Anything outside of that is custom metacpan data/structure.

Likely adding to the confusion is that, as of Sun, 11 May 2014 10:41:02 GMT, `02packages` lists two different versions of bignum: ``` bigint 0.32 F/FL/FLORA/bignum-0.32.tar.gz bignum 0.32 F/FL/FLORA/bignum-0.32.tar.gz bigrat...

I updated the UI to mark the release as unauthorized, but the dist is still incorrectly marked as latest. I made an issue on the api for that (cpan-api/cpan-api#315).

That's not a bad idea. This `bignum` case would still show RAFL's as `latest` (which would agree with PAUSE), but it wouldn't incorrectly break the majority of cases (where installing...

I think this makes sense. Should we add a "checksums" hash with a "git_sha1" in it in case we want to add others in the future?

Hmm... it looks like the App-Pinto dists have been backpanned and App::Pinto is now available in the Pinto dist... so there's definitely a bug there about what's being displayed, or...