rt.perl.org is shutting down about problem-solving HOT 57 CLOSED

To expand a bit on that, imagine you were to rename an org like perl6. Right after the rename you'd need to quickly register a new org under the original name (hoping that no bot or someone else does it before you), and then also hope that github will not drop any of the redirects (including API endpoints and other stuff). It is possible, it's just a lot scarier :)

from problem-solving.

Can we try and schedule this for the near future?

I've approved PR #126. In principle there's a 2 week voting period on that from all reviewers, however I'm also, as assignee, happy to use the shortcut mechanism if there are no dissenting opinions within the next few days.

from problem-solving.

1

from problem-solving.

Actually, after thinking more about it, I think I'd feel more safe by going through the process. That will require all devs to agree and has a side effect of actually making sure that everyone is aware of what will be going on. I'll submit a PR soon.

from problem-solving.

I am in the process of doing a test migration here: https://github.com/Raku/p6rt/issues. Note that most of the issues in the queue are closed.

Please let me know if you see any migration issues. The final migration will likely happen this week.

from problem-solving.

Fixed.

from problem-solving.

{
   "Creator" : {
      "RealName" : "System Attendant",
      "Name" : "[email protected]",
      "NickName" : null,
      "Id" : "5646",
      "EmailAddress" : "[email protected]"
   },
   "CustomFields" : {
      "Platform" : "",
      "VM" : "",
      "Severity" : "",
      "Tag" : "",
      "Perl6Implementation" : "",
      "Patch Status" : ""
   },
   "Owner" : {
      "NickName" : null,
      "Name" : "Nobody",
      "Id" : "10",
      "EmailAddress" : "",
      "RealName" : "Nobody in particular"
   },
   "LastUpdatedBy" : {
      "RealName" : "Leon Brocard",
      "EmailAddress" : "[email protected]",
      "Id" : "508",
      "NickName" : "Leon Brocard",
      "Name" : "acme"
   },
   "EffectiveId" : "29524",
   "Status" : "rejected",
   "Resolution" : "0",
   "Id" : "29524",
   "AdminCc" : [],
   "Subject" : "ScanMail Message to sender: eManager settings were matched and ac tion was taken.",
   "Links" : {
      "DependsOn" : [],
      "MemberOf" : [],
      "RefersTo" : [],
      "ReferredToBy" : [],
      "Members" : [],
      "DependedOnBy" : []
   },
   "Queue" : "16",
   "Requestors" : [
      {
         "EmailAddress" : "[email protected]",
         "Id" : "5646",
         "NickName" : null,
         "Name" : "[email protected]",
         "RealName" : "System Attendant"
      }
   ],
   "Priority" : "0",
   "Resolved" : "2004-05-25 20:24:42",
   "Cc" : [],
   "Created" : "2004-05-12 08:30:19",
   "LastUpdated" : "2004-05-25 20:24:43",
   "Transactions" : [
      {
         "TimeTaken" : "",
         "Creator" : {
            "RealName" : "System Attendant",
            "EmailAddress" : "[email protected]",
            "Id" : "5646",
            "Name" : "[email protected]",
            "NickName" : null
         },
         "OldValue" : "",
         "NewReference" : "",
         "ObjectId" : "29524",
         "id" : "87280",
         "Field" : "",
         "Created" : "Wed, 12 May 2004 01:30:20 -0700",
         "ObjectType" : "RT::Ticket",
         "Data" : "",
         "Type" : "Create",
         "Attachments" : [
            {
               "Created" : "2004-05-12 08:30:20",
               "TransactionId" : "87280",
               "Filename" : null,
               "OriginalContent" : "**************** eManager Notification *****************\n\nThe following message was blocked because it contains sensitive content.\n\nSource mailbox: [email protected]\nDestination mailbox(es): [email protected]\nRule/Policy: Melissa Virus\nAction: Delete\n\nContent filter has detected a sensitive e-mail.\n\n******************* End of message *********************\n",
               "Parent" : "0",
               "Headers" : "Received: (qmail 1533 invoked by alias); 12 May 2004 08:30:16 -0000\nReceived: (qmail 1521 invoked by uid 424); 12 May 2004 08:30:15 -0000\nReceived: from [209.208.177.65] (HELO exchange.nj.aptegrity.com) (209.208.177.65) by x1.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 12 May 2004 01:30:13 -0700\nReceived: by exchange.nj.aptegrity.com with Internet Mail Service (5.5.2653.19) id <15Q36NBM>; Wed, 12 May 2004 04:29:22 -0400\nDelivered-To: [email protected]\nDelivered-To: [email protected]\nMIME-Version: 1.0\nSubject: ScanMail Message to sender: eManager settings were matched and ac tion was taken.\nX-Spam-Status: No, hits=0.0 required=7.0 tests=\nReturn-Path: <[email protected]>\nX-Mailer: Internet Mail Service (5.5.2653.19)\nX-Spam-Check-BY: x1.develooper.com\nDate: Wed, 12 May 2004 04:29:18 -0400\nMessage-Id: <E693DE68445C064FA112BAFE0A5EFD2503D4B714@exchange.nj.aptegrity.com>\nContent-Type: text/plain\nTo: \"'[email protected]'\" <[email protected]>\nFrom: System Attendant <[email protected]>\nX-RT-Original-Encoding: utf-8\nContent-Length: 394",
               "Creator" : "5646",
               "Subject" : "ScanMail Message to sender: eManager settings were matched and ac tion was taken.",
               "ContentType" : "text/plain",
               "MessageId" : null,
               "id" : "61795"
            }
         ],
         "OldReference" : "",
         "NewValue" : "",
         "ReferenceType" : ""
      },
      {
         "ReferenceType" : "",
         "Attachments" : [
            {
               "Creator" : "508",
               "Headers" : "MIME-Version: 1.0\nContent-Type: text/plain; charset=\"utf8\"\nX-Mailer: MIME-tools 5.411 (Entity 5.404)\nContent-Disposition: inline\nContent-Transfer-Encoding: binary\nX-RT-Original-Encoding: utf-8\nX-RT-Original-Encoding: utf-8\nRT-Send-CC:\nContent-Length: 5",
               "Subject" : "",
               "ContentType" : "text/plain",
               "Parent" : "0",
               "MessageId" : null,
               "id" : "62555",
               "TransactionId" : "88163",
               "Created" : "2004-05-25 20:24:41",
               "OriginalContent" : "SPAM.",
               "Filename" : ""
            }
         ],
         "Type" : "Comment",
         "NewValue" : "",
         "OldReference" : "",
         "ObjectType" : "RT::Ticket",
         "Data" : "No Subject",
         "Field" : "",
         "Created" : "Tue, 25 May 2004 13:24:41 -0700",
         "id" : "88163",
         "ObjectId" : "29524",
         "Creator" : {
            "RealName" : "Leon Brocard",
            "EmailAddress" : "[email protected]",
            "Id" : "508",
            "Name" : "acme",
            "NickName" : "Leon Brocard"
         },
         "NewReference" : "",
         "OldValue" : "",
         "TimeTaken" : ""
      },
      {
         "ObjectId" : "29524",
         "id" : "88164",
         "TimeTaken" : "",
         "OldValue" : "new",
         "NewReference" : "",
         "Creator" : {
            "RealName" : "Leon Brocard",
            "NickName" : "Leon Brocard",
            "Name" : "acme",
            "EmailAddress" : "[email protected]",
            "Id" : "508"
         },
         "OldReference" : "",
         "NewValue" : "rejected",
         "Attachments" : [],
         "Type" : "Status",
         "ReferenceType" : "",
         "Created" : "Tue, 25 May 2004 13:24:42 -0700",
         "Field" : "Status",
         "ObjectType" : "RT::Ticket",
         "Data" : ""
      }
   ],
   "Type" : "ticket"
}

from problem-solving.

If I'm not mistaken, there's almost no activity on RT whatsoever (judging by reportable's weekly reports). It feels like we don't even need to move these tickets anywhere and a read-only archive will do.

from problem-solving.

Ideally, someone should review the tickets to see what's worth keeping, but having been on the practical end of that in the past, I understand it's a big ask with potentially not enough payoff.

from problem-solving.

from problem-solving.

Tagging @jnthn as well.

from problem-solving.

"Nothing to do." is a perfectly fine answer. Just need to get that confirmed.

I'm happy to set up redirects, if a mapping can be provided. Or there's always the static archive we'll likely be setting up for perl5.

from problem-solving.

To make sure nothing get's lost I would recommend to put the single files it in a github repo. Or are there any non public information in it? Decision if this would just be archived for historic reasons or if there are tickets which need further processing has to be done by someone with more perl6 language background.

from problem-solving.

from problem-solving.

from problem-solving.

I think there are still valuable tickets in rt that have not been migrated. Especially those that have been with Perl 6 for a long time still sometimes retrieve an rt ticket they remember for an issue that has croped up again. So I'd at least like to have them accessible individually and searchable. (not just a single zip or similar)

from problem-solving.

from problem-solving.

If I understand correctly @rspier is setting up a read only archive viewer for the perl5 tickets that I suspect allows browsing. Can we just put the perl 6 tickets there as well?

from problem-solving.

There are also lots of references to RT tickets in commit messages, comments and test fudges. A read only mirror will definitely be appreciated.

from problem-solving.

@JJ Moving the old stuff to GitHub definitely simplifies your life.

@PatZim Correct. Alpha quality preview at https://rt-archive.perl.org/perl6/ (demo/demo)

from problem-solving.

I've already developed a significant amount of code that automates migrating all RT tickets into a github repo's issues. If you guys would like me to do that for the perl6 queue, I'm happy to help.

Todd

from problem-solving.

@toddr what about redirects? What's going to happen with links to the old tracker?

from problem-solving.

@toddr what about redirects? What's going to happen with links to the old tracker?

Old urls would redirect to the migrated github issue. The top of the migrated issue in github would provide a link to a read only archived version of the RT ticket.

from problem-solving.

@toddr I've sent you an invitation to the perl6 org. If you need your privileges to be elevated to “admin”, let me know. We have not yet decided on the repo we want the tickets to be transferred to, so no action should be taken right now, but I'll keep you updated. Thanks!

from problem-solving.

@toddr btw what happens with closed tickets? They'll redirect to the read-only version or the migration will create and close github tickets?

from problem-solving.

@toddr btw what happens with closed tickets? They'll redirect to the read-only version or the migration will create and close github tickets?

Create and close.

from problem-solving.

@toddr here's a repo to transfer the tickets to: https://github.com/perl6/old-issue-tracker/issues

from problem-solving.

If we create tickets in perl6/XX, can we transfer those eventually to rakudo/rakudo for the ones that are rakudo related? (which is the majority of the RTs)

from problem-solving.

@coke No, unless github lifts that limitation. Things are difficult either way, which is why I filed #46 in the first place. For example, say we want to organize a squashathon to work on these old tickets (closing the ones that are no longer valid, writing some tests for the ones that were fixed, etc.). Doing so in perl6/ is easy, a lot of people have access, and we can give access to those who don't. The same in rakudo/ is also possible, but I always feel like a criminal whenever I give access to those who have not signed a CLA :) (and the CLA process is painful, I guess you know). There was a more recent discussion about moving rakudo/rakudo (log) and about the CLA (log and more). I wish to simplify things one day.

You're right that the majority of tickets there are about rakudo, but then again, the queue is called perl6, and it does contain non-rakudo tickets. So should one specific compiler get the whole ticket queue? Maybe, but given that the RT queue gets almost zero attention nowadays (according to reportable reports), I consider most of these tickets to be museum items rather than valid tickets anyway.

@coke How much bigger the old-issue-tracker→rakudo traffic do you expect to be than old-issue-tracker→problem-solving?

from problem-solving.

I think it's like 80/90% rakudo. But I'm not touching this ticket migration, so don't do anything in particular on my account, I was just curious.

from problem-solving.

I think it's like 80/90% rakudo.

I think this was accurate, but given how long these tickets were sitting with no action, I think many of them should go through problem-solving because some extra discussion or decision is required. I looked at the list of the most recent RT tickets (first page) and it's around 70% that can meaningfully go to rakudo/rakudo, and I expect that value to be even lower for tickets that are older.

from problem-solving.

To clarify, it seems that the tickets on RT roughly fall into two categories:

1. Tickets that should now be in rakudo/rakudo (majority of the tickets on RT)
2. “Other” category, meaning tickets that should go to one of the repos (perl6/problem-solving, perl6/user-experience, perl6/roast, perl6/doc, etc. and sometimes moarvm/moarvm)

So the question is which one of the two options we find more attractive:

1. We create perl6/old-issue-tracker, as I propose. Then we move the minority of the tickets from that new repo into appropriate places, leaving behind just pure rakudo tickets (we will likely mark them with rakudo label). It's unclear what can or should happen with that repo in the future, but one of the options is to transfer it to rakudo/old-issue-tracker later once it is fully clean (which will take one or two squashathons).
2. If we create rakudo/old-issue-tracker, then it's a bit more complicated. I don't think anyone is going to be happy about transferring hundreds of tickets into rakudo/rakudo, so only the most important ones will be moved. So that repo will remain a soup of all kinds of tickets (because other ones cannot be easily moved out). It is a good option if we want to focus on resolving RT bugs, but I think we'll be able to clear that issue tracker much faster if we do it the other way.

If anyone disagrees, please let me know and we'll start the official problem-solving procedure.

from problem-solving.

@AlexDaniel Any updates on the plan from your side? We're trying to keep this moving.

Thanks!

from problem-solving.

@toddr this is an alternative viewer that we used: https://web.archive.org/web/20181121184441/https://fail.rakudo.party/

It seems to parse tags/labels like this: https://github.com/zoffixznet/r6/blob/6f18d34fa67eb906ebe1c53de4431fcb5493a304/lib/R6/RT/Client/REST/Lazy.pm#L80

However, that regex does not include numbers, but it should. It should also include a dot as it seems.

from problem-solving.

This is about to happen now. Are we ready for this? @AlexDaniel did you do the PR? Since apparently the old issue repo has been created and anyway we need to transfer stuff there, and @toddr is kindly offering himself to do that, can we proceed with that and then act on the issues in that repository?

from problem-solving.

@JJ I got carried away by other stuff. We'll get it done eventually. Last time I discussed it with @toddr we realized that it'd be nice to have email → github handle mapping for perl6 contributors, that's what I was supposed to do. Otherwise I believe @toddr++ has everything needed for transferring the tickets.

I also have a draft for a PR to this repo with a short plan on how it'll go, just need some tuits to finish it up…

from problem-solving.

from problem-solving.

I'm reclassifying this as a rakudo issue because it was primarily a rakudo issue tracker. @rba please let me know if you disagree.

Anyway, there's now a PR describing what will be done: #126

from problem-solving.

Can we try and schedule this for the near future?

from problem-solving.

Thank you. It should be relatively non-controversial. No new perl6 tickets have been created in RT in 9 months. Some older tickets are still being updated through the web UI.

The Perl5 conversion went very smoothly, and looks great.

from problem-solving.

@toddr any news?

from problem-solving.

I assumed I was waiting for a green light from @jnthn

from problem-solving.

@toddr well, #126 was merged, so there's now a green light indeed :)

from problem-solving.

@toddr, how is it going? :)

BTW I moved the repo to https://github.com/Raku/old-issue-tracker and gave you the privs there too. That'd be our new github org.

from problem-solving.

@toddr fwiw, still waiting for it to happen! Let me know if there's anything that needs to be done on our side.

from problem-solving.

I just noticed the creation of https://github.com/Raku/p6rt, however it automatically got people subscribed to the repo. You can probably use https://github.com/Raku/old-issue-tracker while we figure it out, but even that has a subscribed ever though the description says not to subscribe :)

from problem-solving.

Let me know what I should do about it. I can't find a way to disable automatic watching. I think I can temporarily remove owner privileges from people so that we can create a few test repos.

from problem-solving.

@AlexDaniel Sorry I'm not sure where best to ask this, but why do we have a new Github org named "Raku" instead of renaming the "Perl6" org to "Raku"? Github allows renaming I believe.

from problem-solving.

@duncand I can't find the final discussion about it, but there's one here. Github does allow to rename organizations, but it's not without issues (though right now I can't say which one is more painful). We already started transferring repos one by one and it will be fine.

from problem-solving.

The test migration is complete. I need someone to review it and someone to give me the go ahead on what org/repo they want it in.

Keep in mind please that wherever you put this needs to be semi-permanent because the redirects from rt.perl.org will go to this destination so if you later move the repo, you break all the redirects.

Thanks,
Todd

from problem-solving.

@toddr it looks perfect to me, much better than I would've ever done it. I'm extremely grateful for all the work you guys did.

As for the labels, the colors can be extracted from https://github.com/rakudo/rakudo/labels/ so that the labels are consistent between the repos (capitalization can be stolen from there too). It's just colors, so if that'd take too much time there's no need.

The final repo should be https://github.com/Raku/old-issue-tracker (decided here). The name is perhaps not the most beautiful but it's very explicit and that's how it should be (e.g. p6rt no longer means much because even some core devs never used RT, and the language is no longer p6).

from problem-solving.

The final migration is complete and available at https://github.com/Raku/old-issue-tracker/issues

@rspier will be setting up redirects at rt.perl.org shortly.

from problem-solving.

Thank you!

from problem-solving.

Redirects should be live now.

from problem-solving.

@rspier thanks for all of the work you've done for RT all these years
@toddr thanks for taking care of the import into GitHub

from problem-solving.

Is it possible to get links to github working on rt-archive? For example:

https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126209

But clicking on the link leads to https://github.com/raku/raku which doesn't exist.

from problem-solving.

Thank you!

from problem-solving.