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:

• Status QUO: we stay with RedMine and just live on as we do now
• Move to hosted Github and try to export/copy current issues from Redmine to Github
• Move to hosted Github BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github

??? (not sure if these are options)....

• Move to hosted Gitlab and try to export/copy current issues from Redmine to Gitlab
• Host Gitlab ourselves and try to export/copy current issues from Redmine to Gitlab
• 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 OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github
• Host Gitlab ourselves and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github

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 promisses 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:

• we could host it ourselves, OR start with hosted version
• more open the Github

AGAINST:

• less known/advanced then Github?