From 5635d93f8ea46c7a4a1cae7c508fbe54634770b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=BCrgen=20Fischer?= Date: Wed, 21 Feb 2018 21:47:45 +0100 Subject: [PATCH] Updated QGISbugtracker (markdown) --- QGISbugtracker.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/QGISbugtracker.md b/QGISbugtracker.md index 5ddbe91..2ed153d 100644 --- a/QGISbugtracker.md +++ b/QGISbugtracker.md @@ -81,13 +81,14 @@ PRO: - 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 percieving that their 'open sourceness' is 'diluted'. If everything must be FOSS then we should apply that standard right through our project : no windows builds, no mac builds, 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... +- 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