Categories
Miscellaneous

RT – Action Plan for CPAN Authors

CPAN RT is going away. CPAN authors have until the beginning of March to extract any useful information from it.

RT is the “Request Tracker”, a bug tracking system that is written by Best Practical. For almost as long as I can remember, anyone who uploads a module to CPAN gets a free ticket queue for their module at rt.cpan.org. MetaCPAN assumes that’s where people should report bugs in your module and helpfully adds an “issues” link that goes to the appropriate page in RT.

But now that system is going away. It will be switched off on the 1st March 2021. The Perl NOC team is spread pretty thinly and they just don’t have the resources to keep it running.

Gabor has published a video talking about what this means and some of the potential problems. But I thought it would be useful to work on a list of things that CPAN authors should be thinking about over the next three months.

Firstly, and most importantly, you’ll need somewhere new for people to report problems with your modules. For most people, that’ll be simple enough. If you host your code repos somewhere like GitHub, then you could just use the issue trackers that most of those services provide. If you host your own code repos (or don’t have public code repos), then you’ll need to find an alternative solution.

Next you’ll need to tell people where to find your new bug tracker. You do this by adding it to the metadata for your CPAN distribution. If, like most people, you provide a Makefile.PL in your distribution, then you’ll want to add a snippet like this to your code:

It’s likely that you already have a “resources” key in your data structure (containing, for example, a link to your code repo), in which case you just need to add the “bugtracker” key inside it. When you release this new update to CPAN, the “issues” link will change to point to your new bug tracker.

You then have the problem of dealing with the tickets that are currently in your RT queues. I suggest one or more of the following strategies:

  1. Go through the list and fix any that can be easily fixed. I found two like that when looking through my list this morning. If you’re releasing new versions of the modules (to add the new bug tracker information) then you might as well fix a bug or two at the same time.
  2. Look for tickets that can be closed. My list contains some very old tickets. I mean like fifteen years old. If someone had a problem installing one of your modules fifteen years ago and hasn’t followed-up more recently, then there’s a good chance that they no longer care about the solution. What I’ve been doing is to check on CPAN Testers to see if anyone else has seen a similar problem. If I see other reports, I know that it’s something that needs to be fixed. If there’s just the one in RT, then I close it with a message saying (paraphrased) “if this is still a problem that you’d like me to investigate, then please open a new ticket at [link to new bug tracker]”.
  3. Then you’re left with the tickets that you’d still like to address at some point. The Perl NOC team say that they’ll probably make a static archive of the old RT tickets available. But it would be good to get those tickets over to your new bug tracker. As I’m using GitHub for my new bug trackers, and that’s currently the most popular solution other than the CPAN RT itself, I’m hoping that someone cleverer than me will write some code that will make moving the tickets easy. But if nothing happens before the end of January, I might have to look into that myself.

I’ve got a bit of work to do in this area myself. Although I’ve been using GitHub for all of my CPAN code for a long time, I haven’t been advertising the fact that I’d prefer people to use GitHub for bug reporting too. So I need to update all of my modules with the new bug tracker information included. I’ll do that over the next few weeks.

I have a couple of tools that might help in this process. Firstly, I’ve just added to CPAN Dashboard a column that links to the module’s bug tracker if one exists. I can use that to know which modules need to be updated.

You could add yourself to CPAN Dashboard if you wanted to get that information for your modules. But if you don’t want to do that, I’ve written a really short program that you can use to find your CPAN distributions that don’t include the bug tracker information. It’s available as a Gist.

Have I missed anything? I mean, yes, I know there are a large number of unmaintained CPAN distributions that no-one will get round to updating. But this post was aimed at active CPAN authors. If there’s anything else you think we should be doing, then please let me know in the comments.

Categories
Miscellaneous

Down the rabbit hole

Blog posts are like busses. You wait months for one and then two come along on consecutive days!

Yesterday I wrote about how we didn’t need a blogging platform for the Perl community – all we really needed was a good-looking feed aggregator. I mentioned Perlsphere as one such aggregator.

Then Matthew commented, saying that Perlsphere looked a bit broken as Dave Cantrell’s posts from a few years ago frequently pop up there as new posts. I had a quick look at the problem and couldn’t quite work out what was going on. His web feed seems valid, but Perlsphere didn’t seem to recognise the dates of the posts.

Perlsphere is implemented using Plagger, a feed aggregator written by Miyagawa a very long time ago (back when it seemed that web feeds were going to conquer the world). It’s a pretty complex beast and it seemed possible that somewhere deep in its code, it was mis-parsing Dave’s web feed. So I cloned the repo and tried to work out what was going on.

But Plagger hasn’t been updated for a very long time. As you can see from the test results, it stopped passing its tests a long while ago (I suspect when the current directory was removed from @INC). I spent a brief time trying to get it working but, ultimately, decided it was too hard a job.

So I took another look at Perlsphere. And I decided that if it’s based on bit-rotten software, it’s not going to be very easy to maintain (which gave me flashbacks to blogs.perl.org!)

But there’s another Perl tool for aggregating web feeds. And I wrote it. It’s called Perlanet (and, boy, do I regret that name now). Back in the first decade of this millennium, I was fascinated by web feeds and the idea of using them to build local “planets” – a web site that aggregated web feeds that had interesting information about your local area. Of course, that was back in the days when everything had a web feed and it was simple enough to pull them together and create really quite interesting sites. These days, of course, web feeds are rather unfashionable and almost no-one thinks to add them on to their web site.

However, they still cling to life in the world of blogging. Mainly, I suspect, because blogging platforms added them fifteen years ago and just haven’t bothered to remove them yet. And it’s blog posts that we’re interested in here – so we’re still in with a chance of building something useful.

And that’s what I did over lunch. I give you Planet Perl, a new site for aggregating Perl blogs.

Currently, it only has four blogs in the configuration. But the config file is on Github and I’ll be happy to get pull requests adding other blogs.

I hope you find it useful.

Categories
Miscellaneous

Blogging for Perl

I think it was at YAPC Copenhagen in 2008 that a small group of us first discussed the idea of building a shared blogging platform for the Perl community. It was over a year later that we launched blogs.perl.org.

I remember a lot of discussions over that time where we tried to thrash out exactly what we wanted to build. I know that one of my main drivers was that I wanted to replace the journals feature of use.perl. For those of you too young to remember, use.perl was a Perl community web site from the dawn of time. The site ran Perl news on its front page, but users could also have their own journal. For a few years, we had a nice little blogging community on the site. It used the same software as Slashdot and, like Slashdot, was looking pretty dated at the time. I remember being particularly disappointed that you couldn’t put images in a journal entry.

So that was certainly where I started from when planning blogs.perl.org. I wanted a modern blogging platform to replace use.perl. Other people wanted slightly different things. At least one person argued strongly that what we really needed was a nice-looking blog aggregator and that people could do their actual blogging on their own sites (or some other blog provider).

But, as you can see, that point of view lost out and we implemented a full blogging system using Movable Type.

Ten years on, I think that was a mistake. I think that having a community blogging platform for Perl is actively harmful to Perl.

I’ll explain why a bit later, but first let’s talk through a bit of more recent history of the site.

It’s well-known, I think, that the site is not is a good state. I’m happy to explain what happened there, but it’s a long and rather dull story. There have been a couple of attempts to build replacement systems but they both stalled before they were complete.

So we’re left in a situation where the site is broken and no-one really has the time or the expertise to fix it. And attempts to replace it seem doomed to failure.

Earlier this year I decided that the situation was untenable and that I wanted to close the site down. I spoke to Aaron and he pretty much agreed with me. We decided that we’d give people plenty of notice to take their blogging elsewhere and, rather than closing the site completely, we would make it read-only (so all the existing content would still be there). We ran the idea past the rest of the loose “management team” and Aristotle spoke up, saying that he would rather take the site over himself and try to improve matters. And that’s what happened. Over the last few months, Aaron and I have extricated ourselves from running the site and it’s all now handled by Aristotle.

I wish him all the best in those endeavours and really hope he manages to make the site better than it was (he’s already making great progress in removing loads of old spam blogs from the site).

But, really, I think that my original plan was a better idea. I don’t want people to blog about Perl on a Perl community site. I want people to blog about Perl on sites where people blog about other languages and technologies.

I’ve been giving talks about the need for the Perl community to break out of its echo chamber for almost as long as I’ve been part of the community. But I think it’s important. It’s a kind of low-key marketing. If you’re talking about your cool Perl project on a Perl community web site then only people who are looking for Perl articles will find it. But if you blog about it on a general programming web site then a) you’ll get a far bigger audience and b) some of that audience might say “oh! I never knew Perl could do that – perhaps I’ll give it a closer look.”

And that’s why I think blogs.perl.org (and, probably, use.perl before it) are harmful to Perl. It encourages Perl bloggers to blog for the Perl community – when it would be far better to get your blog posts in front of more people. Perl people will still read your Perl posts (through Perlsphere perhaps, or post the link to /r/perl or the Perl Community Facebook group) but other people will see them too. On blogs.perl.org, you’re pretty much guaranteed that only Perl programmers will see your posts.

To be honest, I don’t understand why people still use blogs.perl.org. Until Aristotle’s work bears fruit it’s painfully broken. What do you get that’s worth putting yourself through all of that pain? Why not just blog somewhere else and submit your web feed to Perlsphere? Or blog where other programmers blog – somewhere like dev.to, perhaps (I’ve started publishing my more technical blog posts there).

I think it will be great if Aristotle gets blogs.perl.org working well. I really want that to happen. But it would be even better if he didn’t have to. If people stopped using it; if they went off and started spreading their interesting Perl blog posts all over the web.

Break out of the echo chamber. Find yourself a bigger audience. Spread the word beyond the Perl community.

Or, alternatively, explain to me why it’s so vital that the Perl community has its own centralised blogging platform.

Categories
Miscellaneous

The Best of Perl Hacks

What do you do when you’re stuck inside because Coronavirus means that your country is in lockdown? Well, you write a book, of course. Or, to be more accurate, you cobble together fifty or so old blog posts into a book.

So that’s what I’ve done. Now you can read some of your favourite Perl Hacks blog posts in a handy Kindle book. Other ebook marketplaces are, of course, available – but I haven’t had the time to make a version that’s available from anywhere else yet. That might follow if enough people ask for it.

The book is, predictably, called The Best of Perl Hacks and it’s available from Amazon now (that link goes to the UK store, but it should be available on all Amazon sites).

Please buy it, read it and let me know what you think.

Categories
Miscellaneous

Several Small Bits of News

A few little bits and pieces, none of which justify a blog post to themselves.

blogs.perl.org

Some of you will have seen that Evozon’s grant to replace blogs.perl.org was cancelled a couple of months ago. This made me sad as I (along with the rest of the blogs.perl.org team) really want to see the current, fragile, set-up replaced as soon as possible.

I’m happy to see that a new grant proposal has been received from a team at Booking.com. They want to take Evozon’s work, along with some other improvements that they’ve made in house and complete the project.

I’d really like to see this grant approved and the project completed. Please feel free to add your comment to the proposal.

Perl News

Who remembers use.perl.org? For many years it was the best place to go for both Perl news and Perl blogs. The idea behind blogs.perl.org was to replace the blogging part of that site and a few years ago, Leo Lapworth and I built perlnews.org to replace the other part of the equation.

Unfortunately, neither of us really had the time to invest in the site and it never really took off. These days there are plenty of other places to get your Perl news, so we’ve taken the decision to close the site down. The existing stories will remain online and I might replace the current WordPress installation with a static site at some point in the future.

The Perl Conference in Amsterdam

A couple of my recent blog posts have been about deciding what training course to run alongside The Perl Conference (The Conference Formerly Known As YAPC Europe) in Amsterdam.

Unfortunately, my plans had a big collision with Real Life and I’ve realised that it’s just unrealistic for me to have enough time to prepare for the conference. So, sadly, I’ve made the decision that I won’t be in Amsterdam this August.

I’m sure it’ll be a great conference though and I wish the organisers the best of luck with it.

Web Application Development in Perl 6

Gabor asked me to give him a quotation explaining why I had backed his Indiegogo campaign to write a book on web development with Perl 6. This is what I sent him:

I’ve been largely ignoring Perl 6 development since the project started in 2000. I figured that I would have plenty of chance to catch up with it before clients started expecting me to know it. The official release of Perl 6 eighteen months ago means that the time is now right for me to start taking an interest. A lot of the code I write drives web sites, so I want to get up to speed with web development in Perl 6 quickly. That’s why I supported this crowdfunding campaign – I want to read this book and I think that Gabor is the right person to write it.

I think this will be a very useful book. You might consider backing it too.

CPAN Badges

I’m a big fan of the badges from shields.io. I use their CPAN badge on my dashboard. Unfortunately, this badge has stopped working – it just says “cpan | invalid”.

I did some investigation and discovered this was because they use the MetaCPAN v0 API – which has now been switched off. It was simple enough to patch the code to use the v1 API. I’ve sent them a pull request, but it hasn’t been accepted yet.