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?
• user frustration if requirement for mantra is resurrected
• spam if mantra (or suitable replacement) is not resurrected

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
• Voted for and approved by community vote (including proxy votes for user groups which includes many more people than just the number of votes listed in loomio)
• Issue tracker is really nice and simple
• Drag and drop files and screenshots / gifs into the ticket which are then displayed inline makes it a really rich and descriptive platform for describing tickets
• ability to create ticket template so we can guide the user what details to include
• full text search and tag / user etc based filtering makes it quick to find tickets
• markdown is very easy to use for submitting tickets
• integrations of ticket API with other services means we can e.g. synchronise tickets with redmine
• single environment for code and tickets
• minimal project 'churn' / disruption - we are only updating the ticket system not all the other moving parts of the project
• integration with IDE's (e.g. pycharm)
• 3rd party integrations e.g waffle.io offers many opportunities for adding richer ticket management tools / SCRUM etc.

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
• Redmine integration available (https://docs.gitlab.com/ce/user/project/integrations/redmine.html)

AGAINST:

• less known than Github ?
• Some features are Enterprise-version only ( OpenCore model)
• This is not simply moving our issue tracker - it involves moving our code too
• GitHub is already working well for us for many years with no issues, switching to a new infrastructure creates a lot of flux with no obvious benefit. Our time, money and resources are better spent on our code not on our infrastructure
• Philosopy: Do we really required that everything we use is FOSS? Many (thousands) of OpenSource projects happily use GitHub to host their code without them perceiving that their 'open sourceness' is 'diluted'. If everything must be FOSS then we should apply that standard right through our project : no windows support, no mac support, not oracle, mrsid, ecw etc etc allowed. If we don't mind some non FOSS elements in our project then it would be much more pragmatic to just stay on GitHub where we already have everything set up...
• 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.
• 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??