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

Created QGISbugtracker (markdown)

Richard Duivenvoorde 2018-02-21 15:52:57 +00:00
parent 87567a82ec
commit 6b5d2610ad
1 changed files with 55 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
QGISbugtracker.md Normal file

@ -0,0 +1,55 @@
Options:
- Status QUO: we stay with RedMine and just live on as we do now
- Move to hosted Github and try to export/copy current issues from Redmine to Github
- Move to hosted Github BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github
??? (not sure if these are options)....
- Move to hosted Gitlab and try to export/copy current issues from Redmine to Gitlab
- Host Gitlab ourselves and try to export/copy current issues from Redmine to Gitlab
- 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 OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github
- Host Gitlab ourselves and try to export/copy BUT only for QGIS 3.0 issues (actually start with a clean sheet), making Redmine readonly OR only accept 2.x issues from now on (and tell 3.0 issues to move to Github
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?
Move to Github
==============
PRO:
- we will have one system for both code and issues
- free (as in beer) system, without need of hosting it
- GitLAB promisses easy path to GitLAB in case of move
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:
- we could host it ourselves, OR start with hosted version
- more open the Github
AGAINST:
- less known/advanced then Github?
-