Sujets abordés en résumé:
- Objectif de reversement des développements en 2012
- Vision et roadmap
- Avancement et enseignements de janvier et février
- Pourquoi la communauté a besoin de vous
1/ Un des objectifs de BibLibre en 2012
Je suis actuellement responsable des développements chez BibLibre et un des objectifs fort de l’année est d’intégrer dans la version communautaire les développements financés en 2011 par nos clients. La première raison de ce billet est de vous informer de nos travaux et de nos projets sur ce point. Les moyens mis à disposition de BibLibre sont 3 mi-temps (non financés). Ces 2 jours et demi par semaine pour chaque développeur pourront être utilisés à envoyer des patchs, signer et faire du contrôle qualité. Paul a expliqué le contexte et la stratégie dans un de ses billets de blog.
2/ Vision du reversement et feuille de route envisagée
La liste des développements de 2011 et 2012 est dans un document google que vous devriez pouvoir lire.
Ce document évolue, je pense que j’ai atteint une liste assez complète mais elle mérite certainement des affinements (les développements 2010 notamment). Ce document et son suivi ne présument en rien de la complexité du développement. Un développement qui prend une ligne dans ce tableur peut faire 10 lignes de code ou 500.
Nous sommes pilotés par les priorités et demandes. Une des fortes demandes concerne les développements autoure des modules acquisitions et périodiques (plus de la moitié des développements 2011 listés) commandés par l’UJM de St Étienne. François en a fait une présentation à la KohaCon 2011. C’est avec cette priorité que nous avons démarré en janvier et février. Le développement de l’intégration de Babelthèque à Koha a aussi été priorisé puisque un des client demandeur devrait passer sur la 3.6 prochainement.
Il y a également beaucoup de temps qui a été investi dans l’intégration de Solr à Koha, il n’est pas représenté dans le document mais je vous confirme que c’est un beau morceau, tant par sa technicité que par sa difficulté de l’inclure à la version communautaire. J’aimerais démarrer ce chantier avec d’autres personnes externes à BibLibre lors du hackfest 2012 hébergé à Marseille la semaine du 19 mars.
Ensuite, nous devrons nous occuper des autres développements et ce en fonction de nos impératifs et autres missions de BibLibre. L’objectif est que, à la fin 2012, tous les développements commandés par nos clients (ou investis par l’entreprise) aient été proposés à la communauté et suivis de la façon la plus intelligente possible (par exemple, tout soumettre aujourd’hui n’aurait pas de sens car les patchs soumis seraient constamment repris les mois suivants).
3/ Avancement sur les 2 premiers mois de 2012
J’essaie de construire des outils pour suivre l’avancement de nos travaux et vous donner un maximum de visibilité. Ces outils s’affineront sûrement au cours de leur utilisation. Un d’entre eux est une courbe de progression (que j’appelle dans « mon » language un « burndown chart »). Il y a deux principales métriques que j’ai envie de suivre:
- le nombre de patchs soumis
- le nombre de patchs validés et intégrés dans la version officielle
Concrètement, le graphique obtenu montre d’ores et déjà que nous soumettons plus de patchs que ceux qui sont réellement intégrés. Le rythme de nos soumissions permettra de tenir l’objectif mais celui de la validation et l’intégration ne dépend pas de nous.
4/ La communauté a besoin de vous!
La validation et l’intégration dans la version officielle nécessite ensuite un autre acteur que BibLibre !
L’intégration communautaire peut être découpée en trois grande phases (référence: http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow):
- 1/ la soumission des patchs, leur correction s’il y a des retours – équipe technique BibLibre pour ces devs à priori
- 2/ la signature des patchs (validation fonctionnelle appelée « Sign Off ») – tout le monde
- 3/ le contrôle qualité (validation technique appelée « QA ») – équipe de QA élue par la communauté
Une fois que les étapes 2 et 3 sont passées, il n’y a plus de barrière à ce que le patch soit intégré (le release manager fusionne les patch à la version « master »).
Les phases 1, 2 et 3 ne peuvent être réalisées par le même acteur (BibLibre ne peut pas proposer, valider fonctionnellement et techniquement un patch) et ceci pour élargir, les points de vues et les cas de tests. C’est là que j’en viens à la 2e raison de ce billet : vous faites partie des acteurs évident de l’intégration de ces développements à la version communautaire.
Nous faisons également des efforts pour limiter au maximum les barrières techniques. Par exemple, Paul a lancé des bacs à sable pour tester et signer des patchs sans écrire une ligne de commande.
Nous avons beaucoup de travail à fournir et je veux vous faire prendre conscience que nous ne sommes pas les seuls à pouvoir faire avancer les choses !
Merci à ceux qui m’ont suivi jusqu’ici. Je me ferai un plaisir de répondre à vos questions.
Rappel des documents pour le suivi:
Références:
