La saga Bzr la plus fidèle à l’esprit d’Emacs
(thanosapollo.org)- En 2008, Emacs a étudié Git et Bazaar comme successeurs de CVS, et les benchmarks montraient que Git était de très loin plus rapide
- Richard Stallman a confirmé le choix de Bazaar au motif que c’était un paquet GNU, et les discussions techniques n’ont pas fait changer cette décision
- Pendant la croissance de GitHub entre 2008 et 2012, les contributeurs d’Emacs ont dû apprendre Bazaar pour contribuer, puis Canonical a licencié l’équipe de développement en 2012
- En 2013, la stagnation de la maintenance de Bazaar et un bug de la branche ELPA ont relancé le débat, et ELPA a finalement migré vers Git
- En 2014, après le travail de migration d’Eric S. Raymond, Emacs est passé à Git, mais les difficultés d’apprentissage de Git chez des contributeurs clés sont apparues immédiatement après
2008 : Git était plus rapide, mais Bazaar a été choisi
- En mars 2008, Emacs voulait quitter CVS pour un outil de gestion de versions plus moderne, et les candidats finaux étaient Git et Bazaar
- Git était l’outil créé par Linus Torvalds pour le noyau Linux
- Bazaar était un projet GNU maintenu par Canonical
- Sur emacs-devel, une discussion de 236 messages s’est engagée, et plusieurs développeurs ont benchmarké les deux outils
- Andreas Schwab a jugé que
bzr logmettait plus d’une minute à démarrer et était « si lent qu’il en devenait totalement inutilisable » - David Kastrup a noté que
git logs’exécutait presque instantanément, alors que Bazaar, qui reçoit explicitement les informations de copie, déplacement et renommage de fichiers, semblait devoir être plus rapide
- Andreas Schwab a jugé que
- Les chiffres concrets montraient aussi une nette avance de Git
git log | head -1prenait 0,012 seconde, contre 21,5 secondes pour l’équivalent avec Bazaar- Un commit modifiant un seul fichier prenait 0,08 seconde avec Git, contre 17 secondes avec Bazaar
- Le mainteneur principal de l’époque, Stefan Monnier, estimait que la question n’était pas tant de savoir si Bazaar était plus rapide ou plus lent que Git, mais qu’il devait être « suffisamment rapide » pour qu’Emacs puisse migrer, et qu’au minimum
bzr diffne devait pas prendre plusieurs secondes - Le développeur Bazaar de Canonical Jonathan Lange a proposé, pour le checkout initial, une procédure combinant
wget,tar,bzr init-repo,bzr branch,bzr pull --remember- Cette procédure était longue et manuelle, au point de contraster avec
git clone
- Cette procédure était longue et manuelle, au point de contraster avec
La décision d’utiliser un outil GNU
- Quelqu’un a demandé aux mainteneurs et décideurs d’Emacs quelles informations supplémentaires il faudrait pour les convaincre qu’à ce moment-là, bzr n’était pas l’outil approprié
- Richard Stallman a répondu que ce choix n’était pas une décision pour l’instant présent, mais une décision de long terme, et qu’il valait mieux attendre quelques mois que les développeurs de Bazaar améliorent l’outil plutôt que de prendre une décision temporaire difficile à annuler
- Dans un message séparé, Stallman a tranché : « La question est close et la décision est prise. Nous utiliserons GNU Bzr. Parce que c’est un paquet GNU. »
- À la critique selon laquelle des arguments techniques étaient effacés par une décision politique, Stallman a répondu que la règle de soutien mutuel entre paquets GNU faisait mieux fonctionner l’ensemble du système GNU
- À la question « pourquoi ne pas faire de Git une partie du système GNU ? », il a répondu qu’on pouvait l’inclure dans le système GNU, mais qu’il était peu probable que les développeurs de Git veuillent en faire un paquet GNU
- Malgré les benchmarks de 2008, les 236 messages de discussion et la procédure de contournement proposée par un employé de Canonical, le résultat n’a pas changé : Emacs a choisi Bazaar parce que c’était un paquet GNU
2008–2012 : diffusion de Git et coût de l’usage de Bazaar
- Alors que GitHub a été lancé en 2008 et a rapidement grandi, les contributeurs d’Emacs ont dû apprendre Bazaar, qu’ils n’utilisaient nulle part ailleurs, pour soumettre des patches
- Sur emacs-devel, des fils consacrés aux problèmes de Bazaar revenaient régulièrement
- « Help me unstick my bzr, please »
- « Can NOT bzr the emacs repos (may be bzr has a memory leak) »
- En 2012, Canonical a licencié l’équipe de développement de Bazaar
- Par la suite, l’état de maintenance de Bazaar est devenu un poids encore plus important dans le développement d’Emacs
2013 : stagnation de la maintenance et retour du débat sur Git
- En mars 2013, un an après l’arrêt de fait du développement de Bazaar, John Wiegley a demandé à nouveau si Emacs pouvait passer à Git
- Le développement de Bazaar était de fait à l’arrêt
- Des bugs majeurs affectant le développement d’Emacs, comme ceux du dépôt ELPA, restaient pendant des années dans le bug tracker sans être corrigés
- Cette discussion a elle aussi généré environ 200 messages
- La première réaction de Stallman a été de dire que le mainteneur de Bazaar corrigeait certains bugs, et qu’il avait lui-même demandé la veille un correctif pour le bug de la branche ELPA, donc qu’il voulait laisser un délai raisonnable
- Dmitry Gutov a demandé s’il n’était pas trop tard, puisque ce bug avait déjà 1,5 an
- Stallman a expliqué qu’il essayait de déterminer si Bazaar était effectivement maintenu et qu’il espérait obtenir la réponse « oui »
- Joakim Verona a jugé que la communauté Bazaar était très serviable, mais qu’il existait beaucoup de bugs et de patches bien connus, dont certains fournis par des développeurs Emacs, qui n’avaient toujours pas été intégrés en amont après des années
- Stallman a répondu qu’il n’avait pas le temps de lire la mailing list de Bazaar et que la seule mailing list de développement qu’il lisait était emacs-devel
- À la question de savoir si les utilisateurs de Bazaar devaient avoir voix au chapitre pour juger de la suffisance de sa maintenance, il a répondu qu’il tiendrait compte des informations pertinentes, mais qu’il n’était pas approprié de donner aux utilisateurs une « voix » dans cette décision
La critique de Karl Fogel et le problème de la délégation
- L’auteur de Producing Open Source Software et l’un des premiers développeurs de Subversion, Karl Fogel, a critiqué la manière dont Stallman jugeait la situation de Bazaar ainsi que l’absence de délégation
- Selon Fogel, si Stallman n’avait pas le temps d’examiner de près l’état du développement de Bazaar, il lui serait difficile de juger avec compétence si Bazaar restait un bon choix pour Emacs
- Il a soutenu que, s’il n’avait ni le temps ni la disponibilité mentale pour cette évaluation, il devait déléguer aux mainteneurs d’Emacs
- Fogel estimait qu’interroger une seule personne sur un seul bug ne pouvait pas servir d’indicateur indirect de la santé d’un projet, et que d’autres participants au fil avaient déjà mené des recherches bien plus approfondies
- Stallman a répondu que c’était « parce qu’il y avait plus en jeu qu’Emacs »
- La question centrale était le signal envoyé aux autres paquets GNU si un projet phare de GNU abandonnait un outil GNU
- Fogel a de nouveau demandé que Stallman consacre le temps nécessaire pour évaluer de façon fiable l’état de maintenance de Bazaar, ou qu’il délègue à quelqu’un capable de le faire
- Stallman a seulement répondu qu’un plan existait déjà et était en cours d’exécution, sans fournir de détails, de calendrier ni de délégation
ELPA passe d’abord à Git
- Lors de la discussion de 2013, Stefan Monnier a déclaré qu’il n’avait pas d’attachement particulier à la poursuite de l’usage de Bazaar ou à un passage vers Git, Monotone, Darcs, Mercurial, OpenCM, Fossil, etc.
- Ce qui importait immédiatement à Stefan, c’était de sortir la branche ELPA de Bazaar
- Parce que Bazaar ne gérait pas correctement la branche ELPA
- Leo Liu a souligné que la plupart des projets GNU n’utilisaient pas Bazaar
- Selon lui, corriger les bugs de Bazaar pouvait être bénéfique pour Bazaar, mais nuisible à GNU dans son ensemble
- Son argument était que si 20 % du temps libre des bénévoles était absorbé par la lutte avec Bazaar, le coût devenait suffisant pour décourager la participation aux projets GNU
- Plus tard dans l’année, Stefan Monnier a migré vers Git la branche ELPA qui était cassée sous Bazaar
- La branche ELPA souffrait d’un bug provoquant des conflits pendant le checkout, et il ne restait plus personne pour le corriger
- Stefan n’aimait pas l’idée d’un système à deux outils, Git pour ELPA et Bzr pour le trunk, mais il n’y voyait pas d’autre issue
- Il a précisé qu’il ne fallait pas élargir ce changement à un débat sur les mérites comparés de Git et Bazaar, ni à une discussion sur la migration du
trunkvers Git
- Le passage d’ELPA à Git a créé le terrain pour la discussion suivante : « si Git suffit pour ELPA, pourquoi ne suffirait-il pas aussi pour le trunk ? »
2014 : le travail de migration d’Eric S. Raymond et la migration réelle
- En août 2014, Eric S. Raymond avait déjà préparé les scripts de conversion du dépôt Emacs
- Il a expliqué que tout le travail difficile était terminé et qu’il ne fallait qu’un préavis d’environ 8 heures avant d’appuyer sur le bouton
- La migration effective a eu lieu en novembre 2014
- Le 13 novembre, ESR a envoyé un message de six mots : « Commits are open. Have at it. »
- Cette transition a été décrite par certains comme heroic
- Après les 236 messages de 2008, les 200 messages de 2013, la maintenance assurée par Stefan, les problèmes répétés de Bazaar et le passage par un système de gestion de versions moribond, Emacs a fini par basculer vers Git
Après la migration : même des contributeurs clés ont dû apprendre Git à partir de zéro
- Dans les jours qui ont suivi la transition, il est apparu qu’une part importante des contributeurs clés n’avait jamais utilisé Git
- Sur emacs-devel, les fils demandant comment utiliser Git se sont multipliés
- « This Is The Git Help Mailing List »
- « git pull fails with merge conflicts. How can this possibly happen? »
- « A simple git workflow for the rest of us »
- « need help adjusting workflow to git »
- « Good book on Git »
- « Obscure error/warning/information message from git pull » a donné lieu à 124 messages
- Si des personnes qui développaient depuis longtemps un éditeur de texte majeur se sont retrouvées à poser des questions élémentaires sur Git, c’est aussi parce qu’Emacs était resté sur Bazaar pendant que le reste du monde passait à Git
1 commentaires
Avis sur Lobste.rs
Travailler sur un projet dirigé par rms doit vraiment faire perdre la tête
Une histoire vraiment impressionnante. Il y a longtemps, j’ai vu dans une université une présentation où Mark Shuttleworth expliquait le Bazaar d’origine, et l’idée d’un système de gestion de versions distribué m’avait vraiment fasciné
Ensuite, la réécriture de bzr est sortie et j’ai complètement accroché. Ça me semblait avoir bien plus de sens que Git, au point que j’y ai consacré des années, en participant à la mailing list, en créant des plugins, et même en essayant de réécrire en C l’algorithme de comparaison des diffs pour le rendre plus rapide
Au final, il est devenu évident que Git avait gagné, mais il m’a fallu pas mal de temps pour l’accepter
D’après ce résumé, Richard Stallman a interdit jusqu’en 2013 que le projet Emacs migre vers Git. Ensuite, Emacs serait passé à Git en deux étapes, fin 2013 puis fin 2014, mais Stallman n’est plus mentionné après le début de 2013
Il soutenait Bazaar depuis des années, alors n’a-t-il vraiment plus posté de messages d’opposition dans les fils de discussion ensuite ? Ou bien avait-il perdu entre-temps son autorité sur le projet Emacs ?
Dans le fil de 2014 lié dans l’article, je n’ai pas vu d’e-mail à son nom, mais il y a peut-être eu d’autres discussions non liées. Je me suis demandé si c’était l’époque d’une de ses démissions à cause d’une controverse, mais non, je pensais à autre chose. D’après Wikipedia, Stallman a quitté la Free Software Foundation en 2019, et n’a même pas quitté le GNU Project
Je ne comprends pas exactement ce qui fait qu’un projet devient officiellement un projet GNU. Est-ce à cause de la licence ? Git et Linux sont tous deux en GPLv2-only, et Bazaar en GPLv2+. Est-ce lié à la cession du copyright ? À l’hébergement du dépôt, du suivi de bugs, des mailing lists, etc. ? À un nom avec le préfixe « GNU » qui fonctionne comme une forme de soutien ?
Il semble clairement y avoir une distinction importante quelque part, mais je ne vois pas bien laquelle ni pourquoi elle compte
Et il y a aussi une erreur off-by-one récurrente :
Vers 2014, j’ai voulu faire quelque chose sur mysql, mais j’ai fini par abandonner après avoir passé toute une journée à échouer simplement à cloner le dépôt et checkout une branche de release ; maintenant, j’ai beaucoup moins honte de cet épisode
Avant ça, j’avais utilisé CVS, Subversion et Mercurial pendant des années, donc je pensais que le problème venait du réseau ou de mon ordinateur. Avant de lire cet article, je ne savais pas que les benchmarks réels de bzr avaient été à ce point catastrophiques, ni que Canonical, tout en utilisant énormément bzr, avait déjà licencié l’équipe bzr
Quelques années plus tard, quand je suis revenu sur mysql pour autre chose, c’était passé à Git, et le fait de ne pas être bloqué avant même de commencer m’a permis de faire un travail intéressant
Super article. J’ai toujours voulu voir comment se déroulaient ces drames de mailing lists, sans jamais avoir le courage d’y plonger moi-même. La construction du récit et les extraits sont vraiment excellents
Une histoire confuse, mais racontée de façon amusante. Cela dit, je me demande si le titre ne devrait pas être « The Most Bzr Emacs Saga » plutôt que « The Most Emacs Bzr Saga »
Employer « Emacs » comme adjectif n’est pas totalement inédit, mais ça reste un peu étrange
Bazaar a été le premier système de gestion de versions que j’ai utilisé. À l’époque, je découvrais Linux via Ubuntu, et Canonical utilisait Launchpad pour héberger le code source
Avant ça, je ne mettais mon code nulle part, et utiliser Launchpad avec Bazaar me paraissait assez cool. Évidemment, mes projets étaient trop petits pour que je ressente le moindre problème de performances