Re: rt.cpan.org is going away

I share your frustration, Paul. My own few personal modules really only 
required changing the bugtracker URL, but even still, the historical 
bugs that have been closed will be gone, so tracking regressions will be 
difficult. I opted to semi-automatically generate a rich text file of 
all the issues, that I'll be including in GitHub (where my repos are 
hosted, and where new bugs are tracked).

But those are the easy ones. I also run a much larger PAUSE account for 
my company, and that would be more akin to the situation you're facing 
with hundreds of dists, a whole mess of open issues, and years worth of 
historical issues that need to be preserved. I have a strategy. I don't 
have a good strategy. I've tasked a junior developer to write a script 
to scrape rt.cpan.org for every open and archived issue and then use the 
https://docs.github.com/en/rest/reference/issues API to migrate them to 
GitHub. With abuse rate limits, it's a slow process and, frankly, a 
hack, but at least it's better than that essential history being gone 
forever.

- Ryan

On 2021-01-21 8:31 a.m., Paul "LeoNerd" Evans wrote:
> ****
>
>    rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
>    [1], is going to be shut down on 1st March this year [2]; 39 days
>    from when I write this email.
>
> ****
>
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.
>
> I am furthermore concerned at the total lack of discussion or response
> that has so far been generated; aside from Karen Etheridge I haven't
> seen any noise of upset being generated at all. Nor am I aware of any
> sort of effort to handle what will become a huge outage of a major
> component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. As yet
> I have no clue what I am going to do about it. Existing bugs need to be
> moved somewhere else (and I have no clue how I'm going to fix up URLs
> that currently point to those, in code comments, documentation, blog
> posts, ... anywhere else), and a new for users to report new bugs needs
> to exist. Of special note are the numerous "in progress" tickets I have
> across my distributions, containing ongoing discussions about design
> issues and the like. To say that I am "concerned" is an understatement;
> I am fairly close to panicing about this.
>
> I am quite sure I am but the smallest tip of the iceberg here. Every
> time I mention it on Freenode's #perl or irc.perl.org's #p5p there are
> always new folks who were totally unaware of this fact. This is going
> to hit lots of people in a very hard surprise.
>
> I am therefore interested to know if anyone has any sort of thoughts or
> plan on what to do about this; either
>
>    a) Attempts to take over maintenance of the system as it stands, or
>
>    b) Find an alternative location and implement some sort of
>       mass-bailout in that direction.
>
>
> To emphasise again: in 39 days time the bug tracker used by nearly 80%
> of all of CPAN is going to be shut down and become unavailable for
> either historic or newly-reported bugs. We *need* to find a solution in
> that time. It would be great if we all went the same way, thus making
> the lives of users (and metacpan.org) a lot simpler, rather than all
> scattering in 50 different ways, which will cause a huge splintering of
> what has been a very coherent service so far.
>
>
> 1: Add the "known to be RT" and "unknown" categories of
>     https://cpan.rocks/; because metacpan.org defaults to RT in the
>     latter case.
>
> 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html
>