Le changement de nom de GForge vers FusionForge n'est pas un fork. Toute l'équipe qui bossait encore sur GForge old school a basculé vers le nouveau projet FusionForge. Le problème était plus un problème de différenciation de nom entre GForge 5 AS, GForge 5 Community Edition... et le GForge libre original. Ca devenait difficile de suivre.
L'histoire de GForge est assez amusante car la création du projet vient de la fermeture du code de sf.net par VA Linux. Et finir par redevenir un projet proprio est une belle ironie de l'histoire.
Pour avoir fait partie du projet à l'époque, c'était assez simple : il fallait vraiment refondre entièrement le code et l'architecture (car c'est vraiment vraiment très très moche) et on n'arrivait pas à le financer malgré les clients assez prestigieux qui l'utilisent. Tim Perdue a alors pris la décision de faire cette réécriture en proprio. Perso, j'ai arrêté à ce moment-là car je ne voyais plus trop comment on allait arriver à refondre globalement le truc sans les ressources de sa boîte (refondre ce genre d'appli de fond en comble juste sur du temps perso avec un vrai boulot prenant à côté est assez illusoire).
GForge est un exemple typique de projet sur lequel on arrive à financer le service (installation, développements spécifiques - certains contribués mais ça ne suffit pas) mais où il est vraiment difficile de financer une évolution globale.
Le service prend vraiment du temps et demande des personnes assez compétentes (comme certains le disaient plus haut, c'est assez difficile de trouver des profils appli + système) et au delà du financement, le facteur temps des personnes compétentes devient vite très limitant.
De notre côté, on utilise maintenant une forge qui est vraiment très différente de ce qui se fait actuellement sur le marché : il s'agit vraiment d'un orchestrateur de droits et de services pour les projets et il n'y a plus vraiment de services hébergés en propre (on n'a pas redéveloppé un bugtracker, un gestionnaire de tâches, un browser de sources...).
Typiquement, ça crée des repos CVS, SVN, Git, des Trac, des espaces web où poser des fichiers, des sites Alfresco Share, le tout en quasi temps réel via une file d'attente (plus de symptômes cron qui est passé il y a 5 minutes et qui repassera dans une heure).
Les droits sont gérés via Spring Security, CAS et des modules Perl Apache qui font appel à des services REST qui vérifient les droits sur les projets pour les trucs type ViewVC ou Trac.
On a pu aussi prendre en compte toutes les règles métier de la boîte (ex : tous les développeurs de la boîte ont accès à tous les projets non confidentiels en lecture). Et si on souhaite ajouter un type de service, il suffit d'implémenter la petite couche qui va bien pour le créer, ce qui se fait en général assez rapidement, maintenant qu'on a pas mal d'exemples différents d'intégration.
Après, ça ne convient pas à tout le monde loin de là de ne pas avoir tout intégré dans une même application mais, pour l'instant, je trouve ça beaucoup mieux ainsi que ce qu'on avait avant, compte tenu de notre mode de fonctionnement en interne.
[^] # Re: GForge → FusionForge
Posté par Guillaume Smet (site web personnel) . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 3.
Le changement de nom de GForge vers FusionForge n'est pas un fork. Toute l'équipe qui bossait encore sur GForge old school a basculé vers le nouveau projet FusionForge. Le problème était plus un problème de différenciation de nom entre GForge 5 AS, GForge 5 Community Edition... et le GForge libre original. Ca devenait difficile de suivre.
L'histoire de GForge est assez amusante car la création du projet vient de la fermeture du code de sf.net par VA Linux. Et finir par redevenir un projet proprio est une belle ironie de l'histoire.
Pour avoir fait partie du projet à l'époque, c'était assez simple : il fallait vraiment refondre entièrement le code et l'architecture (car c'est vraiment vraiment très très moche) et on n'arrivait pas à le financer malgré les clients assez prestigieux qui l'utilisent. Tim Perdue a alors pris la décision de faire cette réécriture en proprio. Perso, j'ai arrêté à ce moment-là car je ne voyais plus trop comment on allait arriver à refondre globalement le truc sans les ressources de sa boîte (refondre ce genre d'appli de fond en comble juste sur du temps perso avec un vrai boulot prenant à côté est assez illusoire).
GForge est un exemple typique de projet sur lequel on arrive à financer le service (installation, développements spécifiques - certains contribués mais ça ne suffit pas) mais où il est vraiment difficile de financer une évolution globale.
Le service prend vraiment du temps et demande des personnes assez compétentes (comme certains le disaient plus haut, c'est assez difficile de trouver des profils appli + système) et au delà du financement, le facteur temps des personnes compétentes devient vite très limitant.
De notre côté, on utilise maintenant une forge qui est vraiment très différente de ce qui se fait actuellement sur le marché : il s'agit vraiment d'un orchestrateur de droits et de services pour les projets et il n'y a plus vraiment de services hébergés en propre (on n'a pas redéveloppé un bugtracker, un gestionnaire de tâches, un browser de sources...).
Typiquement, ça crée des repos CVS, SVN, Git, des Trac, des espaces web où poser des fichiers, des sites Alfresco Share, le tout en quasi temps réel via une file d'attente (plus de symptômes cron qui est passé il y a 5 minutes et qui repassera dans une heure).
Les droits sont gérés via Spring Security, CAS et des modules Perl Apache qui font appel à des services REST qui vérifient les droits sur les projets pour les trucs type ViewVC ou Trac.
On a pu aussi prendre en compte toutes les règles métier de la boîte (ex : tous les développeurs de la boîte ont accès à tous les projets non confidentiels en lecture). Et si on souhaite ajouter un type de service, il suffit d'implémenter la petite couche qui va bien pour le créer, ce qui se fait en général assez rapidement, maintenant qu'on a pas mal d'exemples différents d'intégration.
Après, ça ne convient pas à tout le monde loin de là de ne pas avoir tout intégré dans une même application mais, pour l'instant, je trouve ça beaucoup mieux ainsi que ce qu'on avait avant, compte tenu de notre mode de fonctionnement en interne.