Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^2: rt.cpan to close, 01/03/2021

by LanX (Sage)
on Dec 07, 2020 at 09:35 UTC ( #11124770=note: print w/replies, xml ) Need Help??

in reply to Re: rt.cpan to close, 01/03/2021
in thread rt.cpan to close, 01/03/2021

Don't you think the decline of RT is also related to the rise of GitHub?

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^3: rt.cpan to close, 01/03/2021
by Smonff (Scribe) on Dec 08, 2020 at 09:36 UTC

    Recently saw someone closing all of their Github issue trackers (and they had a lot) in favor of RT, but this must be an exception. This person must be very sad now...


      Probably me. :)

      RT has always been my preferred issue tracker, and the one I linked to in META.yml. However, some people were reporting issues on GitHub anyway, which meant I often didn't see those issues. So I closed the GitHub issue trackers for each project not so much because I hate GitHub's issue tracker, but more because having two for each project was bad, and out of the two, I would rather use RT.

      RT being shut down is annoying yeah. I'm currently investigating three routes:

      1. Switch to GitHub issues. GitHub issues is mostly pretty decent if you look at it on a per-project point of view. However, if you're managing a lot of projects, it's less good. You can't move an issue from one project to another, for example; you'd need to close it on one project and open a new one on the other project. RT lets you create a custom dashboard where you can see new issues on all your projects at one glance. This is somewhat possible on Github, but it's a lot less flexible. Maybe I can figure something out with the API though.

      2. Host my own copy of an open source issue tracker. A lot of them suck though. I've set up Roundup for clients a couple of times though, and it's pretty darn nice. Customizing it involves writing Python though. Ewww. Overall, it's still a good option, even if I'd need to shower afterwards.

      3. Write my own issue tracker. Very tempted to go down this route. It would let me manage issues exactly how I wanted to manage them. I started fleshing out an SQL schema. It seems a lot of work though.

      I think I'll probably end up using GitHub in the end; MetaCPAN has pretty decent integration with it, showing the number of open issues like it does with RT. And given the amount of work I'd need to put into setting up and maintaining my own hosted issue tracker, I could put that work into writing custom dashboards for the Github issue tracker using the API.

      And actually switching distros over to use the new tracker is pretty easy. Perl exists. It can be scripted.

        Host my own copy of an open source issue tracker. A lot of them suck though.

        Why not host your own RT? It's open source, fully Perl and you clearly already appreciate some of its features. If I had enough dists to warrant the effort this is the path I would choose.

        You could even open it up to other CPAN authors and end up de facto replacing


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11124770]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2022-05-27 13:20 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (95 votes). Check out past polls.