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

Updated QGISbugtracker (markdown)

Nyall Dawson 2018-02-22 16:44:39 +10:00
parent 2429c64329
commit e6128e48e3
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
QGISbugtracker.md

@ -103,6 +103,6 @@ AGAINST:
- 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 - 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... - 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**: 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. - **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?
- 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 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??