QGISbugtracker

Questions to be tackled

• Keeping history or not ?
• Plan for actions with detailed migration work and associated person in charge
• Agenda : are we really in a hurry ?
• Migrating the codebase alongside the issue or not ?
• Hosting the platform ourselves or depend on an online platform ?
• Use a closed-source software or stick to OpenSource ?
• Have a detailed summary of what is kept and what is lost when migrating
  • issues list
  • issues trackers
  • issues categories
  • issues status
  • issues assignments
  • issues Ids
  • issues URL
  • issues attachment
  • issue creation date
  • issue content formatting
  • internal linking between issues
  • references between issues
  • references between issues and PR / commits
  • versions / roadmaps in issues
  • comments author
  • comments dates
  • issue creator
  • user mapping
  • roadmap items ( = milestones)
  • notifications parameters for each issue/user

Options

• A/ Status QUO: we stay with RedMine and just live on as we do now
• B/ Move to hosted GitHub and try to export/copy current issues from Redmine to Github
• C/ Move to hosted GitHub BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly
• D/ Move to hosted GitHub BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine only accept 2.x issues from now on (and tell 3.0 issues to move to Github)
• E/ Move to hosted Gitlab.com and try to export/copy current issues from Redmine to Gitlab
• F/ Host Gitlab ourselves and try to export/copy current issues from Redmine to Gitlab
• G/ Move to hosted Gitlab and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly
• H/ Move to hosted Gitlab and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making only accept 2.x issues from now on (and tell 3.0 issues to move to Github)
• I/ Host Gitlab ourselves and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly
• J/ Host Gitlab ourselves and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making only accept 2.x issues from now on (and tell 3.0 issues to move to Github)

Analysis of options

Stay with Redmine

PRO:

• ready and working now
• we stay in charge of data(base)
• issue numbering and internal linking working

AGAINST:

• not user friendly enough?

Move to Github

PRO:

• we will have one system for both code and issues
• free (as in beer) system, without need of hosting it
• Github promises easy path to GitLAB in case of move

AGAINST:

• closed system
• nobody was able to mass insert existing issues OR think of moving from Redmine to Github issues
• have to come up with a plan to handle 'tagging'/tagging system of issues to be able to search tickets? I started with some idea in 2015: https://github.com/rduivenvoorde/temp/issues
• have to come up with a plan to either export (some) tickets from redmine OR decide to start with a clean (3.0) sheet??

??? (or keep this option out for this discussion) ???

Move to Gitlab

PRO:

• Gitlab.com allows connecting with GitHub account ( and others )
• we could host it ourselves, OR start with hosted version
• OpenSource version ( community edition )
• Easy install ( Docker )
• Dynamic development and new features are added regularly
• Very good and powerful CI infrastructure
• Moving the source code would allow for a unique infrastructure
• Migration tools available

AGAINST:

• less known than Github ?

• Some features are Enterprise-version only ( OpenCore model)

• IMPORTANT AND IGNORED IN THE DISCUSSION SO FAR: Splintering of resources - we have many repos on GitHub - are we going to move them all? it makes the scope of the task huge.

• IMPORTANT AND IGNORED IN THE DISCUSSION SO FAR: Breaking existing workflows - if we migrate fully to GitLab we need to migrate many other things - commit hooks, CI, all sorts of things people have set up based on the current locations of the source.