Isis3: Redmine to GitHub Issues Transfer

[kaitlyndlee]

Please provide comments.

We have created a test GitHub repo and transferred a few tickets from redmine to Issues. The repo can be found at: https://github.com/kdl222/Redmine2Github_Delete

The python script we used takes a mapping file to convert redmine fields to Issues labels. The file below was used. The commented lines were not used during the transfer, but left for your reference only. We did not transfer most of the statuses to labels because we currently do not see a benefit in doing so. The categories and priorities were commented because there does not exist a label on the ISIS repo Issues that directly corresponds to them.

redmine_type, redmine_name, github_label_name, github_label_color

status, Rejected, wontfix, ffffff

#status, New
#status, Closed
#status, Acknowledged
#status, Assigned
#status, In Progress
#status, Feedback
#status, Blocked
#status, Testing


tracker, Bug, bug, d73a4a
tracker, Crash, bug, d73a4a
tracker, Task, bug, d73a4a
tracker, Feature, enhancement, a2eeef
tracker, Recommendation, enhancement, a2eeef
tracker, Question, question, d876e3
tracker, Documentation, documentation, a8bc0d

#tracker, UserTestPlan


Category, Installation, installation, 4528a3

#Category, API
#Category, Infrastructure
#Category, Applications

#Priority, None
#Priority, Low
#Priority, Normal
#Priority, High
#Priority, Block

Current Notes:
*Authorship of tickets and comments do not transfer.
*Related Issues are being researched.
*Milestones transfer - all Isis versions in Redmine need a mapping.

To do to finalize the transfer:

• [x] Set Redmine to readonly
• [ ] Dump all RM issues to a CSV and archive
• [ ] Determine exact list of RM projects
• [x] Switch configuration from RM test project to RM ISIS3 and others, & GH test to GH ISIS3
• [x] Switch test user account to our management account
• [ ] Complete the username mapping
• [x] Complete the RM version to GH milestone mapping
• [x] Create the JSON files from all RM issues
• [x] Break up the creation of GH issues into right sized chunks to keep GH from triggering DNS
• [x] Push the issues to GH
• [ ] Turn RM off

[kberryUSGS]

Could we use the external redmine URLs, like https://isis.astrogeology.usgs.gov/fixit/issues/5544 instead of the internal URLs? The link will be broken to outside users if the fixit-d one is used.

[jlaura]

Does the internet URL matter at all? If fixit is going to be deprecated, the link will be dead sooner or later.

[jessemapel]

I thought we decided to simply freeze redmine? In this case I think it's worth having the link.

[jlaura]

Yes, but at some point it will end up going away - even if two years from now. Do we clean out the links then because they are all dead?

[scsides]

It might be easiest to remove the Redmine link now, during the migration. Saves us time later when fixit is shutdown. In theory the content will all be in Issues, so why link back to it, even for a short time?

[jessemapel]

@scsides Sounds reasonable to me then.

[kberryUSGS]

@scsides That also sounds reasonable to me. It might be convenient to leave the links in for now for ease of access to compare the converted git issue to the old redmine issue.

[kaitlyndlee]

Relating issues is going to be a little trickier than expected. The script first creates issues corresponding to redmine tickets, then goes back through the issues and updates the descriptions of the issues with a link to their related issues. GitHub has an API limit of 5,000/day, but each issue creation requires multiple API calls. We would have to split the upload into multiple days. However, if we did this, we would get an error if an issue is related to one that has not been created yet. Transferring related tickets would require us to either edit the scripts or run one upload command and make it sleep for a day after a certain amount of uploads. If we ran one command, but it failed 2,000 tickets in, we would have to go into GitHub and delete them all manually before we ran the command again, which would be troublesome.

Is it worth it to transfer relations?

[kaitlyndlee]

What I have gathered from everyone's comments is that we should remove the Redmine link to the original ticket. How does this sound to everyone?

[kberryUSGS]

Is there a way to check when the original ticket was submitted for migrated issues? I noticed that comments have dates, but not the tickets themselves.

[kberryUSGS]

@kdl222 @scsides I'm still interested to know if there a way to check when the original ticket was submitted for migrated issues? I realize that this should have been something I noticed and gave feedback on _before_ the migration (but I didn't until after), and it's probably not possible to change now, but I'm wondering if they were migrated in roughly-time submitted order by ascbot, or is there any other way to get a rough idea just from github?

[scsides]

I don't see a way. It looks like we had the info, but it did not transfer. I missed that too.

[kaitlyndlee]

@kberryUSGS I missed this too. The tickets were migrated from oldest to most recent project by project. The projects were migrated in this order: ISIS, Apollo Pan, CaSSIS, EIS, IPCE, cneteditor, Ground Points, OSIRIS-REx, Jigsaw, and Piecewise Polynomials.

[kberryUSGS]

@kdl222 That is very useful to know, thank you! That's very useful for judging how old/recent the tickets are.

[jessemapel]

@scsides @kdl222 Is all of this work done now? It sounded earlier like only the things being migrated to astrodicuss still need to be migrated.

[kaitlyndlee]

@jessemapel Yes, all of the Redmine tickets we wanted have been migrated.