QGIS issue tracker migration plan - qgis/QGIS GitHub Wiki
QGIS Development platform migration plan
This is an ongoing work and will need approval once it is done. Do not take it as a fixed plan. Contributions welcome, please get in touch if you want to participate.
Edit 2018-06-05 : This migration plan is in no way related to the recent news that Microsoft buys GitHub. This plan has been drafted way before, and is based on feature analysis and is originally triggered by the intention to migrate from Redmine to another issue tracker.
This draft takes Gitlab as a target.
The CI part is not touched in this plan, as a GitHub mirror of the code would be kept to be able to trigger Travis build and CI. Full CI migration to GitLab would be interesting but is not on the critical path and can be worked on later.
Requirements
Issue tracker
- migration of issues
- migration of issues trackers
- migration of issues categories
- migration of issues status
- migration of issues assignments
- migration of issues Ids
- migration of issues URL
- migration of issues attachment
- migration of issue creation date
- migration of issue content formatting
- migration of internal linking between issues
- migration of references between issues
- migration of references between issues and PR / commits
- migration of versions / roadmaps in issues
- migration of comments author
- migration of comments dates
- migration of issue creator
- migration of notifications parameters for each issue/user
Code tracker
- migration of source code and history ( git repository)
- migration of branches
- migration of Tags
- migration of PRs
- migration of PRs authors
- migration of PRs comments
- migration of code comments in PRs reviews
Continuous integration
- compilation
- test
- package building (continuous delivery)
Various
- Opensource solution
- Allow to backups of our issues, code, PRs
Actions plan
- Try a migration of issues from Redmine to a Gitlab instance with the requirements above
- Decide between in-house or gitlab.com ( needed for item below)
- Define user mapping between Redmine users and Gitlab
- email users so they create an account on the target platform if they want to have their issues and comments still assigned.
- Also an opportunity to ask them nicely to clean their issues in redmine.
- Determine how much users kept and lost
- Alternative in case of in-house gitlab :
- automatically create accounts on our GitLab for each redmine account
- Take the decision to apply the plan
- Make public announcement on the forthcoming change
- Define an issue management policy using labels
- Create templates for issues in Gitlab
- Put Redmine in read-only mode
- Launch the real migration of issues
- Make public announcement on the change
- Do a issue triage
- Have Gitlab as a mirror of GitHub Code
- Make Github read-only ( Code & PR)
- Import GitHub code and PRs to GitLab
- Switch code and PR references to Gitlab in all documents
- Document how to input a new issue
- Setup a code mirror on GitHub to keep Travis CI happy
- Convert Travis scripts to GitLab CI
- Shutdown Redmine
Status of requirements tests with Gitlab
Issue tracker
| item | status | notes |
|---|---|---|
| migration of issues | ok | all issues can be migrated |
| migration of issues trackers | ok | trackers are migrated as labels |
| migration of issues categories | ok | categories are migrated as labels |
| migration of issues status | ok | open/closed is respected, full status additionally migrated as label |
| migration of issues assignments | WIP | needs a user mapping file |
| migration of issues Ids | WIP | should theoritically work, not tested. May require shell access to target server |
| migration of issues URL | WIP | should theoritically work, not tested. Require Apache setup on origin server |
| migration of issues attachment | ok | inline images are kept too |
| migration of issue creation date | ok | |
| migration of issue content formatting | WIP | so far formatting is kept, converted to Markdown |
| migration of internal linking between issues | WIP | not tested yet |
| migration of references between issues | WIP | not tested yet |
| migration of references between issues and PR / commits | WIP | not tested yet |
| migration of versions / roadmaps in issues | ok | migrated as milestones |
| migration of comments author | ok | needs user mapping file |
| migration of comments dates | workaround | comment dates are inserted in the comment |
| migration of issue creator | ok | needs a user mapping file |
| migration of notifications parameters for each issue/user | ko | notification parameters are different between redmine and Gitlab and will be lost |
Code tracker
Tested here using Gitlab.com import tool : https://gitlab.com/mhugo/QGIS/
| item | status | notes |
|---|---|---|
| migration of source code and history ( git repository) | ok | through Gitlab import or directly with git remote |
| migration of PRs | ok | PRs are migrated ok with GitLab.com import tool |
| migration of PRs authors | ok | ok with gitlab.com tool for all users registered on gitlab.com. When user does not exists the original user is named in PR comment. Unknown if in-house hosting allows for user creation before and therefore migration of all authors (with which tool ?) |
| migration of PRs comments | ok | with gitlab.com tool |
| migration of code comments in PRs reviews | WIP | to be analyzed in abovementionned repository |
Continuous integration (GitLab CI/CD)
| item | status | notes |
|---|---|---|
| compilation | WIP | |
| test | WIP | |
| package building (continuous delivery) | WIP |
Various
| item | status | notes |
|---|---|---|
| Opensource solution | ok | OpenCore model, Community Edition usable online or on-premises |
| Allow to backups of our issues, code, PRs | ok | if in-house, classic backups. If gitlab.com "export" feature |