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


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<fields> and L<parent>
  - 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.


Search Discussions

  • Kent Fredric at Jan 29, 2016 at 12:41 am

    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 Fredric at Jan 29, 2016 at 12:45 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
postedJan 29, '16 at 12:01a
activeJan 29, '16 at 12:45a

2 users in discussion

Kent Fredric: 2 posts Neil Bowers: 1 post



site design / logo © 2021 Grokbase