http://qs1969.pair.com?node_id=11124817


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

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...

🌸

Replies are listed 'Best First'.
Re^4: rt.cpan to close, 01/03/2021
by tobyink (Canon) on Dec 10, 2020 at 09:50 UTC

    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 rt.cpan.org.


      🦛

        Aside from the fact that it would be a monumental task to replace rt.cpan.org (in dealing with spam from unauthenticated email submissions alone), you can't de facto replace rt.cpan.org without providing PAUSE-account authority to the uploaders to manage their queues. rt.cpan.org currently just has you provide your PAUSE credentials directly, which isn't feasible for new sites - a PAUSE OAuth interface would be very useful for initiatives like this...