This year marks the 10 year anniversary of the Perl Toolchain Summit, formerly known as the Perl QA Hackathon.

The Perl Toolchain Summit provides an opportunity for around 30 Perl developers to get together for four days or so to talk about and develop the infrastructure which surrounds Perl. This includes being able to build modules, being able to test them on multiple systems, being able to find out about them, being able to manage them, and many other related areas.

Salve Nilsen started the QA Hackathon back in 2008 in Oslo, and we returned in 2018 with Salve again being involved in the organisation.

This year I was very happy to discover that a number of people arrived in Oslo with the idea of working on some area of Devel::Cover (the Perl code coverage module) or cpancover (the service that provides coverage information for all of CPAN).

This meant that for me much of the summit was spent in collaboration with people who were doing the real work, and I was very pleased about that - such collaboration, which is facilitated and sometimes only made possible by being together physically, is the purpose of the summit.

One such collaboration was with Joel Berger who implemented a queueing system for cpancover.com. Currently I have a crude shell script which does the work it thinks it needs to do, sleeps for 10 minutes and then looks for new work. This means that there can be a delay of a couple of hours or more between a module being uploaded and the coverage being calculated, especially if the module being uploaded happens to have been uploaded just after another module for which the coverage run takes a particularly long time. With the queueing system Joel has implemented the coverage will usually start to be calculated almost immediately. There are still a few nits to be sorted out, but I hope to put this live in the near future.

For quite a while now I have been trying to find a way to get the coverage information from top-level statements in modules. This has become more important as Dancer, Moose and other frameworks have had more code in top-level statements. Aaron Crane spent some time on working out how this might be done and has come up with a solution which is tantalisingly close, but so far we've not quite got to the finishing line. The problem here is that perl, quite reasonably, recognises that this code will only ever be run once, at the start of the execution and so it throws away the optree as soon as it has been executed. The optree is Devel::Cover's hook into what code has been executed, and persuading perl to leave to optree lying around where we can find it later has proven to be remarkably difficult. I will continue looking at this but thanks to Aaron's knowledge and assistance we may shortly* have a solution. *In relation to the length of time I have wanted a solution.

The UI on cpancover.com is awful, in many ways. Babs has be doing wonderful work on making Perl websites look as if they were created this century. We looked at cpancover and she sees a lot of potential for improvement. However, I do not want the front page of cpancover to be a page that is visited very often. Rather, I would prefer that metacpan linked to the internal cpancover pages and thus metacpan becomes the site to search for coverage data.

So I discussed with the metacpan team how we might incorporate coverage data into metacpan, and use its UI as the main starting point for getting access to coverage data. Mickey spent some time building a system to take the data from cpancover and add it into the the metacpan data. The data still needs to be incorporated into the metacpan UI, but we are almost there.

I talked with Garu about uploading users' local coverage data to cpantesters via Test::Reporter and how we might be able to eventually provide coverage data from many users on different systems in consistent, merged coverage reports. There is a lot of work to be done here, but we might be able to get a simple first step in place without too much difficulty . (By we, I mean Garu, of course. And thus I mean without too much difficulty for me.)

As far as my individual work was concerned, I have managed to get the cpancover reports flowing again. I had been storing and serving all the coverage data I had ever calculated, and I managed to run out of inodes on the partition where that data was stored. I have now implemented a retention policy of only serving the latest three module versions, but older versions are being archived. I also managed to bring the server down for a number of hours, so sorry about that if you noticed.

All in all, this was an extremely productive summit for me with respect to Devel::Cover and cpancover. I consider the Perl Toolchain Summit to be the most important event in my technical calendar and I am extremely grateful to the organisers of this year's summit, as I am to the organisers every year, for all their efforts in making it possible. Its also great to see old friends as well as people who have previously only been known online. Along with the work of the organisers, the summit would not have been possible without the generosity of our sponsors. And, of course, the volunteer efforts put in by the talented and diligent attendees whose ranks I somehow managed to infiltrate.

I'm already looking forward to next year.

Sponsors for the Perl Toolchain Summit 2018

NUUG Foundation, Teknologihuset, Booking.com, cPanel, FastMail, Elastic, ZipRecruiter, MaxMind, MongoDB, SureVoIP, Campus Explorer, Bytemark, Infinity Interactive, OpusVL, Eligo, Perl Services, Oetiker+Partner.