I own the hands performing the migration. What attah guessed is right.
My plan is to migrate only git repositories themselves, without any custom GitLab/GitHub added functionality. Thus what is going to be migrated are:
- all git branches
- git commits in all git branches
- git tags
- issues - not migrated. Sorry.
- relases - I don’t think we ever used those.
- PRs - not migrated. Sorry.
The major reason for not migrating the issues and PRs is that these differ between GitLab and GitHub and migrating them will require more effort, while the benefit of that is questionable.
As for PRs, these will be used in GitHub, so anyone who had a change proposal and submitted it as a PR to GitLab is encouraged to recreate the PR in GitHub. I know I could spend a (non-trivial) amount of time migrating the PRs, however, most PRs that I checked were either old-age, incomplete, or otherwise not worth it. I am pretty sure the PRs that are of worth will either be recreated by the people who submitted them originally, or by the team maintaining the repository.
We are planning to keep the current GitLab instance running in read-only mode for some time after the GitHub repositories are taken into use to allow interested parties to move anything from a current PR to the new repositories.
As for the bugtracker, I am sorry about the situation, but I am unable to do anything about it. The Jolla employees are using an internal bugtracker, and any issue/bug/PR reported elsewhere needs to be mapped to an internal bug anyway, thus it does not matter much if the bug is reported in any Bugzilla, GitLab or GitHub issues, on the Forum, on IRC, or a community beer event. The internal bugs created will not disappear, and will hopefully be resolved by the team.
I will check with the teams to see if they are planning to use the issues or wikis in GitHub, and will lock them otherwise. Thank you for the note about that.