|
Le 28/03/2018 à 14:11, Ward, Evan a
écrit :
Thanks for the heads up. I curious as to the reasoning behind
the switch to GitLab.
It is quite simple:
-
Redmine is hard to maintain because:
-
This tool is very sensitive to the change of version of
underlying Ruby gems.
-
Even when, as we did it, Redmine is installed in a
self-containing Ruby environment (using RVM),
this tool remains affected by the change of native system
libraries on which the Ruby gems depend. Sometimes, the
forge is broken after an insignificant system update
(actually, several debian packages are on hold on the server
because of that).
-
Redmine itself does not manage source repositories. It can
only index existing repositories, created outside the forge.
To address this problem, the Redmine Git Hosting
plugin is used but this plugin is poorly
maintained and the issues are rarely
corrected.
-
So, migrating from Redmine 2.5 (the current used version)
to Redmine 3.4 (the last version) would be a nightmare,
requiring several painful steps.
-
You do not use a Redmine feature that Gitlab does not
provide.
-
Gitlab provides all features you need and, thanks to the
Omnibus package, it is easier to deploy and to maintain than
Redmine. Gitlab have a lot of other advantages over Redmine,
and an impressive dynamic. So, an increasing number of our
teams are switching on Gitlab.
Sébastien
--
Sébastien Dinot
Free Software Expert
CS SI - Space BU - Payload, Data & Applications
Parc de la Grande Plaine - 5, rue Brindejonc des Moulinais - BP 15872
31506 Toulouse Cedex 05 - France
+33 (0)5 61 17 64 48 - sebastien.dinot@c-s.fr
|