-
-
Notifications
You must be signed in to change notification settings - Fork 3k
QGISbugtracker
- Keeping history or not ?
- Plan for actions with detailed migration work and associated person in charge
- Who has the competences to do the work ?
- Who funds this work ?
- 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
- Splintering of resources - we have many repos on GitHub - are we going to move them all? it makes the scope of the task huge.
- 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)
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
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
- some data cannot be migrated 100% clean, most notably the author of a ticket will need to be moved to the ticket description rather than appearing as the real author of the github ticket.
- 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) ???
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
-
among features
- 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
- integration with IDE's
- 3rd party integrations
-
Very good and powerful CI infrastructure
-
Moving the source code would allow for a unique infrastructure ( optional)
-
Migration tools available ( not fully tested)
-
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)
-
(Tim) 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. Many months of development effort has gone into setting up these systems which would need to be replaced. Who will volunteer their time to port them to a different platform?
- (Vincent) : we should first identify the impacts and list the "many other things". This is true for a migration to GH issues too anyway.
-
(Jef + Tim) Philosophy: 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...
- (Vincent) : it is very different to support optional proprietary systems in our software, and have a mandatory closed platform for our project. I am in favor of pragmatic choices, but when choice is possible, then favor OpenSource. I do think we are in a situation where we have the choice here.
-
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
- (Vincent) This is true for GitHub and Gitlab alike. From my experience, labels system generally proves to be simple yet powerful enough to be able to set efficient rules for issue tagging and management.
-
have to come up with a plan to either export (some) tickets from redmine OR decide to start with a clean (3.0) sheet??
- (Vincent) This question is listed on the top of the page
-
(Tim) 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
-
(Tim) This is not simply moving our issue tracker - it involves moving our code too
- (Vincent) Possibly, but not necessarily (hence put this remark here)
-
(Vincent) As for the poll, I personally think that the way the question was asked had a strong bias, as it did not consider any alternative, and was not clear on what would happen in case of a yes or no vote. It also seemed premature to ask at that time, when the discussion on the list was still ongoing with a lot of points still unknown and necessitating more study.
-
(Jorge Gustavo) Moving issues from Redmine to GitLab makes things more simple for new users. We can have more people submitting, reviewing and fixing bugs. With this “small” change, it became much more easy to explain to new comers the QGIS workflow. It also enables a closer integration between tickets and code.
-
(Jorge Gustavo) Move to a completely new infrastructure, like GitLab, is complicated. The wisest path is to move to Github and then move to Gitlab. It will be easier to do such migration in the future, if everything is already in GitHub, but we do not urgently need to change. Let’s do it in smaller steps.
-
(Jorge Gustavo) Moving from Redmine does not mean clear the history. The history is there and we can work there for 2.x. But we have the opportunity filter a very good percentage of quit old issues.