Categories
CPAN

Replacing CPAN RT

Two weeks ago, we learned that the CPAN Request Tracker was closing down early next year. I proposed a plan that CPAN authors could follow to ensure that their users can still find somewhere to report bugs in modules (and, perhaps more importantly, to see what bugs have already been reported in modules).

But that’s only part of the problem. In fact, it’s probably a minor part of the problem. If you’re an active CPAN author, then you probably already knew about the impending closure and had already made plans to deal with it. It’s likely that you had already moved your bug tracking to a new system. At the very least, you now know what the problem is and are considering the best way to deal with it before next March.

The far larger problem is the thousands of distributions that aren’t owned by active CPAN authors. What are we going to do about those?

How big is the problem? Well, the site cpan.rocks displays stats about CPAN. One of the panels on its front page shows a summary of the bugtracker information in CPAN distribution. You’ll see that 24,873 distributions (that’s 66% of them) have no bugtracker information included in their metadata. That’ll be for a number of reasons. Some of them will be distributions that haven’t been updated since alternative bugtrackers were supported by CPAN (originally, it was just assumed that everyone used the CPAN RT); some of them will be because the authors don’t know how to add the required metadata; and some of them (including most of my distributions) are missing it because the author just hasn’t got round to adding it yet. There will, of course, be many more reasons.

Some people will have read the recent news and will be galvanised into doing something about it (I fall firmly into that category) but others (and I’d suggest that it’s a large majority) either won’t hear about the change or won’t care about it. And why should they care? They were generous enough to donate some of their code to CPAN at some point. They don’t have any obligation at all to carry on maintaining it after they’ve lost interest in whatever project led to them writing that software.

Take, for example, Mail-Alias. That was released by someone called Tom Zeltwanger twenty years ago. He released three versions over a period of two months and then stopped. Who knows why. When he last updated the module, the CPAN search engine didn’t support alternative bugtrackers, so he never considered adding one. And that meant that the CPAN page for his module linked to the default bugtracker set up for the distribution on the CPAN RT. In the last fifteen years, four bugs have been reported against that module. But as Tom has moved on, nothing has been done about any of them. There are a lot of modules on CPAN in a similar situation.

But that leaves MetaCPAN (the current CPAN search engine) with a problem. Where does it send people who want to report a bug against an inactive module?

You might think that it doesn’t matter. But I disagree. Maybe I think that Mail::Alias would be the perfect module for a project I’m working on. Even before I start using it, it’s useful to be able to browse any existing bugs to see how they might affect my use of the module. And if someone later comes along and wants to take over maintenance of the module, then it’s useful for them to see any bugs that have been raised during the hiatus when the module was unmaintained.

So, I’m a big fan of having a default bugtracker for CPAN modules – even for ones with inactive authors. Which leads us to the question of where should that be. And I have a suggestion.

A few years ago, Micheal Schwern and Olaf Alders set up Gitpan. It’s an organisation which has a Github repo for every distribution on CPAN. And those repos each have a commit for every release of those distributions. Here, for example, is the repo for Mail-Alias – and you can see the three commits for the three releases I mentioned above.

So I’d like to suggest Gitpan as a suitable place to use as a default bugtracker for CPAN distributions. There are a couple of problems:

  • It looks like the auto-population of the commits stopped a few years ago. We’d need to work out how that works and catch up on the recent uploads.
  • None of the repos has the issue tracker turned on. But I expect that can be done with a relatively simple program that uses the GitHub API.

Of course, we also have the problem that some people object to using GitHub since it was taken over by Microsoft. But that’s fine, they can just point their bugtracker metadata to their preferred system.

The problem with the CPAN RT was that it needed too much maintenance – and the Perl NOC team is really overworked. Any self-hosted alternative seems likely to have the same problem eventually. So I’m all in favour of using a third-party alternative. And if you’re taking that route, then it makes sense (to me, at least) to use a third-party system that already has all (ok, most) of the repos set up.

I haven’t spoken to Schwern or Olaf about this, so I don’t know if there was some major problem that would stop this plan from working. But I think it’s worth looking at.

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.