#gitfr

Plone, le plus gros CMS Libre vient lui aussi de passer sur GitHub. Vous pouvez donc constater la présence de 127 (!) dépôts Git. Ce nombre important vient de la programmation par composant du monde Zope (une fonctionnalité = un composant Python = un dépot Git).

Pourquoi je parle de cette migration en particulier alors que de nombreux projets Libres passent sur GitHub ? Tout simplement car c'est aussi un des plus gros projets Python, langage utilisé par les deux principaux «concurrents» de Git, à savoir Mercurial et Bazaar. Ce choix fait suite à un sondage chez les développeurs pour déterminer la prochaine plateforme d'hébergement (3 réponses possibles : oui, neutre, non) :

• Héberger son prore serveur Git : 10, 36, 33
• Héberger son prore serveur Hg : 8, 18, 53
• Héberger son prore serveur Bzr : 1, 3, 75
• Sur GitHub : 46, 21, 12
• Sur Bitbucket : 8, 18, 53
• Sur Launchpad : 4, 6, 69
• Continuer avec son propre serveur SVN : 28, 30, 21

Ce résultat est révélateur sur plusieurs points :

• Un rejet absolu de Bzr. Personne n'en veut à part quatre personnes.
• Un rejet massif de Launchpad et dans une moindre mesure de Bitbucket (plutôt étonnant).
• Peu de gens sont pour héberger un serveur DVCS, ce qui me semble encore une fois assez étonnant. Il est facile par exemple d'administrer un serveur Hg. Plus un problème de méconnaissance ?
• Plus de la moitié des votants sont en faveur de GitHub, sans être un plébiscite.

La conclusion qui semble se dégager de cette enquête est que c'est encore une fois GitHub qui fait pencher la balance vers Git, et non l'inverse. D'autant plus que choisir Git signifie faire une croix sur la possibilité pour un développeur Python de coder facilement des extensions Mercurial, atout non négligeable quand on gère un projet.

Si la plupart des gens considèrent GitHub comme une superbe plateforme d'hébergement de code, beaucoup sont encore dubitatifs sur la délégation des tickets (bug et/ou fonctionnalité), et préfèrent utiliser Trac, Redmine ou JIRA. Il est donc intéressant d'apprendre que le projet Ruby on Rails (qui pour l'anecdote, est hébergé depuis le premier jour de GitHub) utilise officiellement GitHub pour ses tickets de bugs.

Le retour d'expérience va donc être très intéressant. Et sans nul doute, les GitHubbers (les développeurs de GitHub) seront très sensibles et réactifs aux remarques et retours, étant eux mêmes des utilisateurs de RoR.

On le savait déjà (la décision date d’aout 2008 !) mais voila une très mauvaise nouvelle pour l'outil de gestion de source Darcs. Le principal projet qui l'utilise, à savoir le compilateur Haskell GHC, passe officiellement sur Git, avec un miroir disponible sur GitHub depuis le 31 mars.

Mauvaise nouvelle aussi (et surtout) car Darcs est lui même en Haskell, le projet GHC était donc le premier pourvoyeur (si je ne me trompe pas) de contributions. Mais le point intéressant est l'argument pour passer à Git :

It came down to two things: the degree of support available, and flexibility of the tools (git is much happier to let you modify the history than Mercurial). Speed ruled out bzr, and Windows support is less of an issue: git appears to work reasonably well on Windows these days.

Les développeurs GHC, comme la fondation Eclipse, estiment donc que le support Windows est devenu «raisonnable» pour ne pas gêner les utilisateurs de cette plateforme. Ils estiment aussi que la vitesse est le point faible de Bazaar (bzr). Et enfin, que la capacité de retravailler son historique (point fort que je mets en avant dans toutes mes présentations Git) est un atout important. Point important, cette phrase vient du mail expliquant la migration en 2008 (Bazaar étant maintenant plus rapide, par contre Git est toujours mieux armé pour gérer l'historique).

Est ce la fin pour Darcs ? Un projet Libre ne meurt vraiment jamais tant qu'il existe des utilisateurs. Le développement se poursuit (la 2.5.2 est sortie et la 2.8 est en cours de développement avec le support très attendu de la fonction rebase). Il est dommage pour la diversité de l'écosystème Libre qu'un outil meurt mais Darcs ne semble plus avoir d'atout majeur face à Git.

Pour la petite histoire, Darcs est né en 2002 d'un fork du projet GNU Arch (1er DVCS libre en 2001). L'aspect intéressant de Darcs est qu'il présente non pas l'historique comme une série de «snapshots», mais comme une suite de patchs, qui n'ont pas nécessairement de lien entre eux. Ce qui facilite grandement le cherry-picking. Malheureusement, des performances catastrophiques et quelques bugs génants au moment du merge n'ont jamais permis à Darcs de décoller.

La fondation Eclipse propose maintenant des miroirs GitHub. 70 projets sont d'ores et déjà disponibles, et le mouvement semble enclenché pour que Git devienne l'outil de gestion de source par défaut.

La fondation héberge ses propres projets en proposant CVS, Subversion et Git. Mais la perspective collaborative de GitHub semble être un avantage certain, comme le souligne l'annonce de Chris Aniszczyk :

I'm happy to announce we finally setup mirroring of eclipse.org repositories on GitHub. I think this is an important step to making the eclipse.org codebase more accessible for people to fork and contribute changes.

Et il faut bien évidemment que son projet soit sur Git pour que ce dernier apparaisse sur GitHub...

De plus, InfoQ souligne que c'est l'amélioration d'Egit, le module Git pour Eclipse (la version 1.0 devant sortir pour Eclipse 3.7) qui rend Git attrayant aux yeux des développeurs. Ce qui est confirmé par l'augmentation très sensible depuis plusieurs mois des demandes de migration vers l'hébergement Git que propose la fondation.

C'est donc une énorme communauté qui pointe le bout de son nez dans l'écosystème Git (Eclipse héberge des centaines de projets), signe supplémentaire de la maturité de ce dernier, notamment dans des environnements non Unix. Et on ne va pas s'en plaindre :).

Le projet Drupal est en cours de migration depuis plusieurs mois (le choix de migrer sur Git est décidé depuis février 2010). C'est donc toute une communauté qui faut former à l'outil, mettre en place des nouvelles pratiques, recoder l'infrastructure (intégration continue, deploiement...). Travail important s'il en est.

Aprés une évaluation des différents outils et du choix final, trois étapes et dix sprints de deux semaines sont planifiés. La migration s'étale donc sur environ 15 mois.

Les 3 phases :

• création d'un mirroir Git en lecture seul (recréé régulièrement)
• utilisation de Git en mode centralisé
• utilisation de Git en mode décentralisé

On peut noter que l'équipe infrastructure de Drupal était pour Bzr, mais que la communauté Drupal était majoritairement pour Git. Le choix Hg fut éliminé par manque de soutient.

Voici la feuille de route :

• Sprint 1 - Making key decisions necessary for the project to move forward
• Sprint 2 - Version Control API
• Sprint 3 - VC API / Admin Interface and Migration Script Finalization
• Sprint 4 - Release-Worthy Views for VC API and Git Activity Log
• Sprint 5 - VC API / Project Module Integration
• Sprint 6 - Project Module (Release Nodes being automatically generated for repositories containing appropriately named branches)
• Sprint 7 - Preparation for Broader Community testing
• Sprint 8 - Community Testing
• Sprint 9 - Community Testing and Deployment Preparation
• Sprint 10 - Deployment (CVS will be gone forever)

Vous trouverez les résumés des sprint 1, sprint 2 et sprint 3.

Le mirroir Git est déja en place puisque nous sommes à la phase 2, vous pouvez constater le nombre assez impressionant de dépôts. Les scripts de migration CVS vers SVN sont sur GitHub.

On a vu fleurir les présentations et les formations Git, comme au Bootcamp Git De Los Angeles ou au DrupalCon de Copenhague.

Si vous souhaitez suivre la migration, lisez régulièrement cette page ou par Twitter avec @DrupalGitGremln.

L'équipe qui gère l'infrastructure de la fondation Apache travaille sur le support de Git. Comme beaucoup de projets Libres qui utilisent SVN, de nombreux contributeurs utilisent Git par l'intermédiaire de git-svn, mais ce changement va permettre l'utilisation de Git nativement.

Les discussions sont en cours sur la liste de diffusion et des tickets Jira sont ouverts à ce sujet.

Il va être intéressant de suivre les discussions et la mise en place d'un DVCS sur une aussi grosse infrastructure que celle d'Apache, qui gère beaucoup de projets avec des années d'historique et d'habitude d'un modèle centralisé. Notamment de voir quels worflows ils vont mettre en place.