Re: Need help with GitHub Issues migration

Hello

Three tips come to mind:

1. One of the advantages of using GitHub for project management and work is the GitHub CLI ($ gh):
https://cli.github.com/manual/gh

2. Choose a GitHub UI for project management:
https://github.com/Project-managment-templates

3. Think through the project's use of GitHub labels for both the issues and pull requests:
https://github.com/abdonrd/github-labels
https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues
https://seantrane.com/posts/logical-colorful-github-labels-18230/
https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63
https://climbtheladder.com/10-github-labels-best-practices/

Cheers
Max


On Saturday, February 22nd, 2025 at 7:38 PM, Yury V. Zaytsev via mc-devel <mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org> wrote:

> Hi there,
> 
> TLDR; For the last few weeks I have been working on migrating our issue management from Trac to GitHub. I think the progress so far is significant enough to get some external feedback. I would like to ask those of you who are interested in working with GitHub to take a look at the test ticket import I did this week:
> 
> https://github.com/MidnightCommander/mc-test-1/issues
> 
> (This repository will be removed once the migration is complete. It is now marked as archived because I want to prevent the creation of new issues and the editing of existing ones.)
> 
> I'm interested in whether you find the import readable, and whether there are any formatting problems that are not due to formatting already broken by the posters in Trac. I would appreciate any specific suggestions on how my templates can be adapted to improve the import, with an explanation of why you think this is really better. I've tried my best to get good results, but I can't check every single record, of which we have about a hundred thousand.
> 
> Let me know if your Trac username is not correctly mapped to GitHub and you want it to be. Of course, I was only able to map those users who use the same email for both Trac and GitHub.
> 
> ---
> 
> Now a longer version for those who enjoy more background information:
> 
> ## Current setup
> 
> We have been using Trac for 15 years and it has come of age. The version of the OS, libraries and Trac itself that we are running is no longer supported and is broken in various ways. The machine is set up in such a way that only a complete rebuild is possible to get a new supported OS and a future-proof Trac setup.
> 
> This will be a huge effort, but in the end we'll end up with a system that was cool 15 years ago and not so cool now. On the other hand, migrating to some kind of hosted offering will also be a huge effort, but at least we'll hopefully get access to modern workflows and offload the maintenance of the infrastructure to an external provider.
> 
> As far as Trac workflows are concerned, I'm most bothered by the lack of a proper code review system, as is now possible with GitHub or GitLab. The double accounting with tickets and PRs on GitHub is also annoying.
> 
> As far as hosted options are concerned, the big ones seem to be GitHub and Gitlab. Both offer an acceptable or better alternative to what we have now, especially as far as code review is concerned. GitHub clearly has more traction and better CI (in fact, thanks to GitHub Actions, we now finally have a half-decent CI setup). The project management options used to be underwhelming, but now GitHub Issues really do seem to be able to do most of what Trac can do.
> 
> ## Way forward
> 
> ### Choice of system
> 
> Having said that, I'd like to proceed with GitHub. We've been using it for a long time to host our primary repository. Now we are using it to host the CI. Hopefully we can move issue tracking to GitHub as well, and then consider decommissioning the rest of Trac. I don't think maintaining a self-hosted solution is a viable option for a project of this size and with current resource constraints.
> 
> ### Migration strategy
> 
> When the subject of migration has come up in the past, I've always said that the quality of the migration is of paramount importance to me. I'd go with the tool as long as we kept the huge knowledge base we've built up over more than a decade, and that knowledge base is accessible in a way that's better than what's possible with Trac. Unfortunately, no one ever went further than to suggest that we should do something about it, so no progress was made for years due to a complete lack of resources.
> 
> Now that I have managed to devote a few weeks to the project, I have found a way to preserve issue IDs and timestamps when migrating to GitHub. Unfortunately, the authorship of the posts cannot be transferred. I have worked out a mapping scheme between the Trac and GitHub concepts, and implemented code to import the data.
> 
> As soon as there is agreement within the current development team (basically me and Andrew), we can set Trac to read-only mode (I haven't researched it yet, but it must be possible) and make the move.
> 
> ### Limitations
> 
> * Edit history of descriptions and comments will not be transferred
> * Attachment uploads via the API are not supported and will be hosted in a separate repository
> 
> #### The following fields will only be transferred as timeline entries:
> 
> * Branch state (not needed with PR states -> draft, unreviewed, changes requested, approved)
> 
> * Votes for changeset (not needed with PR)
> * Blocked by / blocking (replaced with sub-issues)
> 
> #### The following fields will be translated
> 
> * Type
> - defect: Bug
> - enhancement: Feature
> - task: Task
> * Reported by (table entry)
> * Owned by (assignee)
> * Priority (labels, 4 grades instead of 5)
> - blocker: "prio: blocker"
> - critical: "prio: high"
> - major: "prio: medium"
> - minor: "prio: low"
> - trivial: "prio: low"
> * Milestone (milestone)
> * Component (labels)
> - mcdiff: "area: mcdiff"
> - mcedit: "area: mcedit"
> - mcview: "area: mcview"
> - adm: "area: adm"
> - compilation: "area: build"
> - crosscompilation": "area: build"
> - documentation: "area: docs"
> - mcconfig-ini": "area: config"
> - mccore": "area: core"
> - mckey-bindings": "area: keybind"
> - mcsearch": "area: search"
> - mcskin": "area: skin"
> - mctty": "area: tty"
> - mcvfs": "area: vfs"
> - tests: "area: tests"
> - translates: "area: i18n"
> - locale: "area: i18n"
> - translations: "area: i18n"
> * Version (labels)
> - Version "master" doesn't make sense and won't be transferred
> * CC -> Mentions (table entry)
> 
> * Keywords (table entry)
> * Resolution (partly labels, partly status)
> - fixed / wontfix / duplicate / reopened - corresponding issue status
> - invalid: "res: invalid"
> - worksforme: "res: worksforme"
> * State (partly status)
> - accepted / assigned - implicit via assignee
> - new - implicit
> - testing - will be removed
> - closed - implicit
> - reopened - reopened
> 
> ### Workflow changes
> 
> I want to keep the workflow changes to a minimum. We can make more changes later if warranted.
> 
> In terms of issue management, I'm planning to add issue templates, adjust PR templates, and add a "Triage needed" label for new issues.
> 
> Otherwise, my idea would be to use "Connect branch to issue" for the cleanup branch, "Prepare for release" tickets, and PRs for what we usually do review for.
> 
> If the branch is in development, a PR referencing the issue can be opened in draft mode.
> 
> If review is required, reviewers are invited. Once approved, the PR can be merged either manually or via the web interface. I'll be looking into workflows to prevent merging via the web interface if the PR has not been properly rebased.
> 
> That's it for now.
> 
> All the best,
> Yury
> 
> --
> mc-devel mailing list
> mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
> https://lists.midnight-commander.org/mailman/listinfo/mc-devel
-- 
mc-devel mailing list
mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
https://lists.midnight-commander.org/mailman/listinfo/mc-devel