http://www.perlmonks.org?node_id=11124690

A short note over at the Perl NOC announced this closure.

Replies are listed 'Best First'.
Re: rt.cpan to close, 01/03/2021
by hippo (Chancellor) on Dec 05, 2020 at 11:34 UTC

    Thanks for highlighting this. I would have been completely unaware otherwise.

    Can't say I agree with this decision at all. Surely having a single place to report issues with any module is a great asset? There's an investment of time, effort and cash to keep it running of course but can that be so huge as to warrant closing the whole site? I hope TPTB will reconsider.


    🦛

      They give the reason as being due to low and declining use so it seems like a case of use it or loose it...

      Guilty!
      I've never used it

Re: rt.cpan to close, 01/03/2021
by Corion (Pope) on Dec 07, 2020 at 10:36 UTC

    davorg has written up an action plan for CPAN authors.

    Ideally, there would be a script to transfer the existing open RT tickets (including attachments) to Github issues, but if rt.cpan.org remains as a static, read-only site, the comments and patches won't be lost either.

Re: rt.cpan to close, 01/03/2021
by hippo (Chancellor) on Feb 20, 2021 at 15:46 UTC

    Brilliant news: Best Practical are to host a fully-functioning rt.cpan.org for 3 years at least. See this TPF post for more.

    This is a fantastic result and means that those of us who made emergency plans to use alternative ticketing systems no longer need to activate them. It's just a shame it couldn't have been arranged beforehand to avoid all this kerfuffle.

    Update: It has been brought to my attention (thanks, LanX) that the linked article text is invisible without Javascript enabled. I have no idea why TPF might have done that but they probably won't mind if the text is repeated here verbatim:

    Since the announcement of the upcoming closure of rt.cpan.org, we've looked at what could, should, or must be done to keep it available in one form or another. After looking at a few options, The Perl Foundation has voted to contract Best Practical to take over the hosting of the CPAN RT instance. Starting immediately, they will be porting the data to their hosting, upgrading the RT instance to the latest version, and adapting the custom RT plugins and code that make rt.cpan.org go.

    This work is expected to take until some time during March. With the current RT install going dark on March 1, this means that there may be an extended downtime at the beginning of the month. We will keep the page at rt.cpan.org up to date with the progress of the project. When the upgrade is complete, we have a commitment for three years of hosting from Best Practical. If future changes are likely or needed, we'll post them well in advance.


    🦛

      "It's just a shame it couldn't have been arranged beforehand to avoid all this kerfuffle."

      It's also a shame that it was so poorly handled, from the initial decision of one person, without offering anyone else the opportunity to pick this up, the fact it wasn't communicated well at all (authors not emailed etc), no community engagement. What a mess. Even now rt.cpan still has the end of life message displayed.

      Update: *one person.

Re: rt.cpan to close, 01/03/2021
by marto (Cardinal) on Dec 10, 2020 at 17:12 UTC
Re: rt.cpan to close, 01/03/2021
by Anonymous Monk on Dec 28, 2020 at 19:32 UTC
    FYI, this was the decision of NOC without consultation of any of the rest of the community, and there is an effort underway to transfer hosting to those who do want to maintain the service. Unfortunately perlmonks does not allow me to post a link to the infrastructure working group discussion.

      There still seems to be some confusion within the community as to what is actually going on here. A Static Archive of rt.cpan.org, I've posted a few comments asking the question and linking to the topicbox thread, but none have been approved by the author yet. Is there a definitive statement anywhere? rt.cpan still shows the sunset message when browsing, there seems to be no link to topicbox in any of perl.org or perl releases that I can find. Some clarity would be much appreciated.

Re: rt.cpan to close, 01/03/2021
by Tux (Canon) on Dec 23, 2020 at 09:41 UTC

    Please use ISO date format in tiles like this or actual month names. This is very confusing.

    I know it is 01 Mar 2021, but with the stupid US date format still being used, the title could easily be misinterpreted.


    Enjoy, Have FUN! H.Merijn

      It happens on 1614556800 :P

      > I know it is 01 Mar 2021, but with the stupid US date format still being used, the title could easily be misinterpreted.

      Punctuation helps me

      01.03.2021 EU format 2021-03-01 ISO format 03/01/2021 Who cares format

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

        I agree with the last two, but to me the first is confusing already, as Europe uses different puntuation everywhere :(

        The dotted DD.MM.YYYY seems to be popular in older EU documents and Post-Soviet states.

        In The Netherlands we use DD-MM-YYYY.

        I think that we are blessed anyway, as Ireland is a lost cause: "In Ireland, the date is written in the order "day month year", with the separator as a stroke, dot, hyphen, or just left blank. The year may be written with four digits or just the final two, sometimes with an apostrophe to mark the omitted first two digits."

        Conclusion: Disambiguate and use ISO! (but whatever you use, never use / and/or D in the middle.)


        Enjoy, Have FUN! H.Merijn

      but with the stupid US date format still being used, the title could easily be misinterpreted.

      It's not just the US.

      For all-numeric date formats,
      Countries representing 1,678 million people have YMD as their official format.
      Countries representing 0.55 million people have MDY as their official format.
      Countries representing 2,974 million people have one of the above as one of their official formats.
      Total: 4,652 million

      Conversely,

      For all-numeric date formats,
      Countries representing 2,871 million people only have DMY as their official format.

      So that makes the numbers in the OP potentially backwards for 62% of the world! And that includes for me Canada, which uses YMD.

      Source

        Countries representing 0.55 million people have MDY as their official format.

        There's a reason that >99.9% of the global population do something else. Putting the least significant of the three date parts in the middle is just being perverse.


        🦛

Re: rt.cpan to close, 01/03/2021
by perlancar (Hermit) on Dec 13, 2020 at 10:08 UTC
    Probably because maintaining the RT installation is a bitch? Anybody has experience in the software? Surely if RT is as easy to install and update as, say, WordPress, maintaining it wouldn't be a big effort?
Re: rt.cpan to close, 01/03/2021
by Don Coyote (Friar) on Dec 23, 2020 at 08:39 UTC

    I'd like to be reassured about the affects on license attribution such a move would incur.

    Also does Raku use CPAN in the same way as Perl? As I understand it Raku is fully GPL 3 licensed whereas Perl 5~ has a GPL 2 license (at the GPL part at least).

    What domain would Github.com reside over in terms of licensing? I always assumed that rt.cpan.org retained license issuing rights over any code submitted, if that makes sense, or at least adhered to the licensing as it arrives with the code.

    Due to my partial understanding of the subtleties of these issues relating in as much as they do to the Perl family, I would like succint and coherent reassurance around such issues.

    For example, will it be necessary for every submission of a tracking request and its responses to be posted with a suitably attached license?

      The choice of bugtracker does not have any impact whatsoever on licensing. IANAL
Re: rt.cpan to close, 01/03/2021
by ikegami (Pope) on Dec 23, 2020 at 13:27 UTC

    That's 2021/03/01, for those wanting an unambiguous date format. (I hate you; I thought I only had a few days left.)

Re: rt.cpan to close, 01/03/2021
by bart (Canon) on Dec 06, 2020 at 14:19 UTC
    The writing's on the wall, Perl is dying... Even the very first supporters are abandoning it: search.cpan.org, kobesearch.cpan.org and now rt.cpan.org...

    Sad news. I still like using perl as much as I did when I first started using it, now more 2 decades ago. It wasn't popular then yet, then... and now it's way past its prime.

      Even the very first supporters are abandoning it: search.cpan.org, kobesearch.cpan.org and now rt.cpan.org

      I've always thought that the demise of kobesearch had more to do with the untimely passing of Randy Kobes, rather than the waning of perl.

      Cheers,
      Rob

      search.cpan.org shut down mostly because a better replacement existed. The URLs still work; they just redirect to MetaCPAN. I don't think it shutting down was indicative of any decline.

      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

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

        🌸