Nicolas Ecarnot a écrit :
Bonjour,
Je connaissais IRMA mais je l'avais écarté pour cause de modèle de base
de données trop mal construit.
Je découvre avec plaisir qu'une équipe francophone reprend le projet et
ça nous intéresse.
C'est vrai que le modele de la base est assez "basique" mais je pense
que c'est suffisant, pour la plupart des utilisations qu'on peux faire
de glpi.
Après une première install, je découvre que je ne peux pas me logguer.
Un peu de débug et je vois que les variables sont postées mais non
récupérées, rapport au register_global à off par défaut depuis plus d'un
an dans les install par défaut de php.
Qu'à cela ne tienne, si vous me confirmez que le problème vient bien de
là, je vais proposer un patch dans ce sens (si vous l'acceptez).
Nous avons déjà reglé ce probleme ainsi que de nombreux petits "bugs"
qui restaient, ce sera implémenté dans la version 0.3 que nous
"realizon" tres bientôt, dans le mois de juin si tout va bien.
De façon plus générale, nous cherchons depuis un bon moment un logiciel
de gestion de parc, mais non automatisé (à la OCSI), et GLPI nous plaît.
Il nous manque surtout une notion d'historique : Nous souhaitons non
seulement gérer notre parc, mais conserver les infos sur l'évolution du
parc.
Acceptez-vous les contributions, avez-vous du temps pour commiter nos
patch, voir même ouvrir le CVS ?
A ce niveau, nous acceptons bien sur, et sommes demandeurs de toute
contribution.
Le CVS n'est pas ouvert, je pense qu'a terme il le sera, mais
actuellement les travaux à réaliser sont trop consequents pour qu'on
laisse chacun contribuer avoir accés dessus comme ça, nous nous en
sortirions plus si c'etait la cas.
Meme si nous y perdons un peu en temps, nous preferons actuellement
passer par cette Mailing liste pour tout ce qui concerne les contributions.
Le principe est simple si on veux contribuer :
1) La premiere chose à faire c'est aller chercher les sources sur le CVS
(en Anonyme), et de tenir ces sources à jour.
2) Ensuite d'identifier les parties sur lesquelles ont veux travailler,
puis en faire part ici sur la mailing liste.
3) Comme ça chacun pourra aller de son commentaire (je pense que c'est
comme ça qu'on fait avancer les choses dans le sens de l'interet général).
4) Et ça permet aussi de ne pas avoir deux contributeurs travaillant en
meme temps sur les memes choses, etant donné que tout passe par ici.
5) Au final vous nous envoyez les fichiers de contribution, les
eventuels diff des fichiers modifiés et nous on integre et verifie ça si
la majorité des presents sur la mailing liste sont pour.
Voila comment nous procedons actuellement, je ne sais pas trop s'il
existe des meilleurs façons de faire pour un projet OpenSource, mais je
sais que jusque là cette methode à bien marchée.
Bien sur c'est une procedure pour les grosses contributions, si il
s'agit d'un patch ou d'un correctif, pas forcement besoin de passer par
toutes les etapes.
Mais dans l'absolu c'est comme ça que je vois le truc, en particulier
car il y a pas mal de structures qui utilisent déjà GLPI en prod et
pour un souci de transparence envers eux, pour leur garantir qu'on ne
fait pas n'importe quoi non plus, et qu'ils ont leur mot à dire je pense
que c'est primordial.
--
Bazile
