[This is a post in my latest long-ass series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.
IMPORTANT NOTE! When I provide you links to code on GitHub, I’m giving you links to particular commits. This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post. Just be aware that the latest version of the code may be very different.]
Last time I rearranged our UI to be (hopefully) a bit more intuitive. This time I want to clean up the remainder of those pesky CPAN Testers failures on our way to the next solid release.
So, the first thing I needed to do was to figure out what all those failures were. See, as I touched on before, CPAN Testers failures tend to come in groups. The trickiest part (usually) is identifying the patterns and figuring out what they have in common, which usually tells you what caused the failures. Once you know what the failures are, it’s often trivial to actually fix them. Often, but not always. We have a bit of a mix here, as it turns out. But first I had to analyze the failures and pick out the patterns.
Except I didn’t have to. Because the Perl community is awesome, and someone thoughtfully did it for me. Literally a day or two before I was about to start wading into the fail reports myself, Slaven Rezić (a.k.a. SREZIC on CPAN, a.k.a. eserte on GitHub) opened three GitHub issues wherein he’d already done all the work for me. So I have to give a big shout out to Slaven: he did the hard part. And, with the hard work done for me, all I had to do was buckle down and just fix the errors.