Odoo est sur Github : enfin débarrassés de Launchpad et Bazaar !
Le passage d'OpenERP à Odoo s'accompagne d'une excellente nouvelle :
Enfin débarrassés de BZR ! \o/
Plus que le passage à git et Github, la vraie bonne nouvelle est l'abandon de Bazaar et de Launchpad, qui étaient un lourd handicap. La fusion des 3 branches bazaar vers un 1 seul dépôt Git devrait pouvoir accélerer les choses et faciliter la contribution. Le processus de contribution n'est pas encore bien défini sur la nouvelle plateforme, il serait fort souhaitable qu'il s'organise autour d'un modèle de remontée de merges, un peu comme le noyau Linux. (Update : les consignes de contribution sont ici : Contributing)
Un autre souhait que nous formulons à Anybox est le renforcement de la politique qualité : un bugfix devrait systématiquement être accompagné d'un test unitaire qui verrouille le bugfix et empêche les régressions. C'est une pratique élémentaire qui diminue les risques, les coûts de R&D et de support, et malgré ce qu'on pense diminue énormément aussi les délais : l'identification et la correction d'une régression prend beaucoup plus de temps que l'écriture précoce du test unitaire. Ce genre de politique est toujours difficile à propager et n'a de chance d'être appliquée que si elle provient à la fois d'une volonté de la direction technique et de la direction générale, et même si c'est le cas, elle demande de la discipline de la part des développeurs. Or elle semble pour l'instant mieux respectée dans les branches communautaires que dans les branches officielles. À bon entendeur.
Gain en temps et en espace disque
Cloner un dépôt depuis Github prend beaucoup beaucoup moins de temps que récupérer une branche Bazaar sur Launchpad. Outre ce gain en temps, on gagne aussi en espace disque. Voici un comparatif des tailles des dépôts :
OpenERP sur BZRopenobject-server154 Moopenobject-addons692 Moopenerp-web33 MoTotal879 MoOdoo sur GitOdoo432 Mo
La seule chose utile qu'on perd avec Git est la notion de shared repository de Bzr. Il suffisait de faire un bzr init-repo dans un dossier au dessus des branches de travail pour mutualiser tous les changesets dans un dépôt commun, y compris de branches forkées. Un moyen de reproduire ce mécanisme avec Git (ce serait la même chose avec Mercurial) est d'utiliser un dépôt référence cloné directement depuis Github, de faire des git fetch depuis ce dépôt quand c'est nécessaire (ou en mercurial hg pull), puis de faire les clones locaux depuis ce clone référence. Étant donné que Git et Mercurial utilisent des hard-links pour faire les clones locaux, chaque clone ne prend quasiment aucun espace disque supplémentaire pour stocker les snapshots ou les changesets, hormis l'espace occupé par les fichiers de travail. Une autre méthode pour alléger les clones consiste à utiliser l'option --depth qui limite la récupération d'historique à une profondeur donnée.