fix form and some more details

Vincent Picavet 2018-02-21 17:48:22 +01:00
parent a555ada6d2
commit 7a1a914d1c

@ -1,4 +1,5 @@
Questions to be tackled :
## Questions to be tackled
- Keeping history or not ?
- Plan for actions with detailed migration work and associated person in charge
- Agenda : are we really in a hurry ?
@ -27,22 +28,22 @@ Questions to be tackled :
- roadmap items ( = milestones)
- notifications parameters for each issue/user
Options:
## 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
- 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)
??? (not sure if these are options)....
## Analysis of 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
=================
### Stay with Redmine
PRO:
- ready and working now
@ -53,13 +54,12 @@ AGAINST:
- not user friendly enough?
Move to Github
==============
### Move to Github
PRO:
- we will have one system for both code and issues
- free (as in beer) system, without need of hosting it
- Github promisses easy path to GitLAB in case of move
- Github promises easy path to GitLAB in case of move
AGAINST:
- closed system
@ -70,14 +70,18 @@ AGAINST:
??? (or keep this option out for this discussion) ???
Move to Gitlab
==============
### Move to Gitlab
PRO:
- we could host it ourselves, OR start with hosted version
- more open the Github
- OpenSource version ( community edition )
- Easy install ( Docker )
- Dynamic development
- Very good and powerful CI infrastructure
- Gitlab.com allows connecting with GitHub account ( and others )
- Migration tools available
AGAINST:
- less known/advanced then Github?
-
- Some features are Enterprise-version only ( OpenCore model)