Re: addressing kwalitee and other quality issues at the head of the CPAN River

[Kent Fredric]

On 29 January 2016 at 13:01, Neil Bowers  wrote:
>  - use warnings


This can be a regression sometimes, adding warnings where there are
none in novice code is good.

But people who know what they're doing may omit warnings on purpose.

So this is not so much a "Quality" metric, but a "Best practices for
most projects"

Proof by example: https://metacpan.org/source/RJBS/if-0.0606/if.pm

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: addressing kwalitee and other quality issues at the head of the CPAN River

[Kent Fredric]

On 29 January 2016 at 13:01, Neil Bowers  wrote:
> adding min perl version


I'd be particularly careful with that one. People who don't know what
they're doing are predisposed to set a bar at a premature location.

For instance, if somebody has a motto of /attempting/ 5.6 support but
doesn't guarantee one, a dist may /appear/ to have a higher minimum
version until one of its dependencies is likewise made 5.6 friendly.

Minimum requirements should be statements of fact and be the lowest of
bars that are viable, not a conjectural "this is probably needed", for
conjectural things, recommends and suggests are better, ( but putting
perl itself in either of those fields is kinda nonsense, because no
CPAN Toolchain can/will transparently upgrade your perl )


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

addressing kwalitee and other quality issues at the head of the CPAN River

[Neil Bowers]

I’ve been looking at CPAN distributions that have 10k+ downstream dependent 
distributions. There are currently just 45 such distributions:

http://neilb.org/2016/01/26/river-head-quality.html

I think that in general these heavyweight dists should be good examples for 
people to look at. Sometimes there will be special reasons why they not 
following all best practices, no doubt, but in general I reckon they should.

But before I start sending pull requests and blead patches for core modules, 
given I know that opinions on kwalitee vary, I figured I should raise the topic 
somewhere.

For example, picking one module, base, I would look at:
 - adding license to the doc and dist metadata
 - adding min perl version
 - add a basic README
 - use warnings
 - add links to parent and superclass in SEE ALSO
 - changes mentions of fields and parent in first para to L and 
L
 - update doc to include discussion of RT#28580, and suggest it’s closed 
(https://rt.cpan.org/Public/Bug/Display.html?id=28580)
 - RT#98621 can be closed (https://rt.cpan.org/Public/Bug/Display.html?id=98621)
 - For RT#98360 see below
 - I’m not familiar enough with fields for RT#68763 
(https://rt.cpan.org/Public/Bug/Display.html?id=68763)
 - Similarly for 28399

Is there an agreed policy for whether blead upstream modules should have the 
perl git repo in the dist metadata or not? Some do and some don’t. Personally 
it’s of questionable value, since I can’t submit a PR, but seeing the perl repo 
URL does at least tell me that it’s blead upstream.

Neil