sharpetronics/QGIS
1
0
Fork 0
mirror of https://github.com/qgis/QGIS.git synced 2025-06-22 00:02:40 -04:00
Code Issues Packages Projects Releases Wiki Activity

Reorganize ideas, questions and remarks at their right place in the page - please stay objective or place your opinions in the last section

Vincent Picavet 2018-02-22 15:27:19 +01:00
parent 9eeb476e5c
commit 43ecfed044
1 changed files with 19 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
QGISbugtracker.md

@ -2,6 +2,8 @@
- 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 ?
@ -27,6 +29,7 @@
- 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.
## Options
@ -110,10 +113,20 @@ PRO:
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. 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?
### Other general comments, notes and personal opinions
- (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
- have to come up with a plan to either export (some) tickets from redmine OR decide to start with a clean (3.0) sheet??
- have to come up with a plan to either export (some) tickets from redmine OR decide to start with a clean (3.0) sheet??
- (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)