NEILB's Blog

A couple of times recently I've had to deal with distributions that have both a Build.PL and Makefile.PL. I've never been sure of the right way to handle such dists, and in both of the recent times I ended up with problems. From talking to various people on IRC and elsewhere, it seems like there's no good reason to have both. Personally I go with Makefile.PL (with ExtUtils::MakeMaker) if it's someone else's dist, or Dist::Zilla if it's a full adoption.

When cleaning up a river, you need a measure for cleanliness, and then you start cleaning, and see whether your measure shows improvement. This post outlines two simple measures that may help us measure overall CPAN quality, and then start working to improve it. These are just early ideas — I'm sure we can some up with something better.

This is the usual quick look at the number of CPAN pull requests that were done in April 2015. Ever-so slightly more than in March (650 vs 643), so the second-best month ever.

There are some distributions on CPAN that were last released 20 years or so ago. Understandably many of them don't follow many of the conventions that we expect today, and some of them fail all their tests, and have for a while. I think we should do something about these dists: either update them to be well-behaved modern distributions, or remove them from CPAN. They'll continue to be available on BackPAN. Here I'll go through a batch of the oldest.

For the CPAN River model to be useful, we need to be able to visualise it, and show people where their dists sit on the river. This post shows some quick hacks done on the sofa this evening. Definitely needs more thought! This is based off data generated by David Golden, which lists all dists and the total number of downstream dependencies each dist has.

This is a collection of suggestions for how to increase the likelihood of a random pull request (PR) being merged. This particularly applies to the CPAN Pull Request Challenge, where you're trying to come up with a PR on a randomly assigned CPAN distribution. These ideas come from feedback I've had from people on the receiving end of random PRs, and discussions with experienced CPAN authors.

The QA Hackathon (QAH) is a chance to spend 4 days with thirty or so other people who care about the CPAN toolchain. I went with a list of things I wanted to work on, but spent a lot of my time working on other things that came up during the QAH. I've come back with my batteries recharged, fired up for another year.

This is a write-up of some ideas that Tux and I bounced round following the CPAN River discussions at the QAH. When doing dev releases of dists that are "up the river", look for changes in the CPAN Testers results of downstream dists to see if you've had a knock-on effect. This could be automated in a 'river smoke tester'.

This blog post describes a model that we found useful for talking about CPAN dependencies and reverse dependencies at the QA Hackathon. At the head of the river is Perl itself with the core modules. The river flows into the sea, which contains all distributions that aren't used by any other distribution. Other distributions sit somewhere along the river, their position determined by their reverse dependencies. This post introduces the core concepts, but nothing more.

This blog post outlines an idea for a service that informs people when their CPAN distributions gain reverse dependencies. Many authors are probably not even aware that their distributions have reverse dependencies, and what the implications of that can be. Sending them an email gives us a chance to congratulate and engage authors, but also to educate and encourage them in some new practices.