Le dépôt de code de Mozilla Firefox migre de Mercurial vers GitHub

• Firefox a récemment migré son dépôt principal de Mercurial vers GitHub
• Le suivi des bugs reste sur Bugzilla, les revues de code sur Phabricator et la CI sur Taskcluster
• GitHub est désormais le dépôt central, mais le serveur Mercurial est toujours maintenu via une synchronisation depuis GitHub, et les systèmes d’automatisation existants doivent eux aussi passer progressivement à Git
• Le dépôt try utilisé pour les tests CI repose encore sur Mercurial, mais il est de plus en plus masqué derrière une couche d’abstraction et devrait être migré vers Git à terme
• Le fait de pouvoir utiliser Git comme base apporte l’avantage de permettre aux nouveaux contributeurs de n’apprendre que Git, sans devoir se former séparément à Mercurial
  • Auparavant, il fallait installer l’extension git cinnabar, mais désormais Git seul suffit
• L’ancien mozilla-central de Mercurial devient la branche main dans Git, tandis que la branche autoland reste autoland
• Le workflow basé sur les PR de GitHub n’a pas été adopté pour l’instant et ne fait pas partie de ce changement. La possibilité existe pour l’avenir, mais aucun plan officiel n’a été annoncé
• Avec cette transition vers GitHub, Mozilla peut réduire la charge liée à l’exploitation de sa propre infrastructure de VCS
• L’objectif principal est de réduire les coûts et la complexité nécessaires pour fournir en interne les performances, la stabilité et la disponibilité exigées par un projet de grande ampleur

Historique détaillé et explications rédigés par Glandium, l’auteur de git-cinnabar : How I (kind of) killed Mercurial at Mozilla

> Mozilla tourne la page de Mercurial en basculant le dépôt de code de Firefox sur GitHub

• Mozilla a décidé de faire passer le VCS central du développement de Firefox de Mercurial à Git et de faire de GitHub le dépôt officiel
• Cette décision s’appuie sur le développement et l’adoption sur le long terme de l’outil d’extension git-cinnabar, qui permettait déjà aux utilisateurs de Git d’accéder facilement aux dépôts Mercurial
• Les problèmes liés à la structure des branches de Mercurial, la croissance de la taille du dépôt et la charge d’exploitation des serveurs internes se sont combinés, entraînant une accumulation des difficultés à maintenir l’infrastructure en interne
• Le choix de GitHub suscite des débats, mais il était difficilement évitable du point de vue de la praticité et de l’accessibilité pour les contributeurs, alors que des milliers de dépôts internes à Mozilla existent déjà sur GitHub
• git-cinnabar était au départ un projet personnel parallèle né d’un besoin interne chez Mozilla, mais il restera probablement un outil important pendant la période de transition
  > « Je n’ai pas allumé l’incendie, mais j’ai bien versé de l’huile sur le feu. »

[GN⁺]

Avis Hacker News

• Je travaille chez Mozilla, mais je ne suis pas impliqué dans l’outillage VCS ni dans cette transition ; voici un peu de contexte supplémentaire. Le dépôt officiel du code de Firefox a récemment été déplacé de Mercurial sur hg.mozilla.org vers GitHub. Cela ne concerne que le code : le suivi des tickets reste sur Bugzilla, la revue de code et l’intégration continuent d’utiliser Phabricator, et la CI repose toujours sur Taskcluster. À court terme, le serveur Mercurial est synchronisé depuis GitHub afin de permettre aux systèmes d’automatisation de migrer progressivement vers un backend Git. Mercurial est encore utilisé pour le dépôt « try » (où l’on exécute la CI sur des patchs en cours de travail), mais il est de plus en plus masqué derrière une couche d’abstraction, et il sera lui aussi migré plus tard. Pour les personnes habituées à l’ancien dépôt, « mozilla-central » correspond à la branche Git standard « main », et « autoland » est mappé sur la branche « autoland ». On pouvait déjà contribuer à Firefox uniquement avec Git, mais cela nécessitait d’installer l’extension git cinnabar. Devoir choisir entre apprendre hg ou utiliser Git avec une extension représentait une barrière à l’entrée pour les nouveaux contributeurs, qui connaissaient généralement Git mais pas Mercurial. Désormais, il n’y a plus à se poser la question. L’auteur de git cinnabar, glandium, a publié un billet de blog avec un contexte détaillé et les raisons de cette migration au moment de l’annonce. À court terme, presque rien ne change du point de vue des contributeurs. L’usage classique de Git devient le workflow par défaut, et à part cela, rien ne change. Un support futur d’un workflow basé sur les PR GitHub pourra peut-être arriver plus tard, mais ce n’est pas inclus dans ce changement. En backend, une fois la migration terminée, Mozilla pourra réduire le temps et les efforts nécessaires pour exploiter sa propre infrastructure VCS ; satisfaire les exigences de performance et de disponibilité d’un projet de cette taille représente un défi considérable
  • Personnellement, je pense que Mozilla a eu tort de migrer vers une plateforme propriétaire appartenant à Microsoft
  • Comme Phabricator a été abandonné, je me demande s’il existe un plan de remplacement ; j’aimerais savoir s’ils envisagent quelque chose comme Phorge
  • Merci pour le contexte supplémentaire. Je me demande quels étaient les principaux problèmes de montée en charge rencontrés avec la solution auto-hébergée
  • J’aimerais savoir si GeckoView et Mozilla Android Components vont eux aussi être déplacés sur GitHub
  • Je regrette que seul le code soit déplacé sur GitHub, tandis que le suivi des tickets reste sur Bugzilla. L’un des grands avantages de GitHub est que beaucoup de gens y ont déjà un compte et connaissent la plateforme, mais comme les tickets ne sont acceptés que sur Bugzilla, cela crée aussi une barrière pour le simple signalement de bugs. J’ai déjà utilisé Bugzilla et Firefox pour signaler un bug d’accessibilité sur macOS, et c’était assez pénible : il fallait trouver le site, s’inscrire et apprendre à l’utiliser. Le bug a fini par être confirmé, mais il n’a pas été corrigé
• Du point de vue stratégique de Mozilla, cela me semble être une décision compréhensible. Les revenus venant de Google diminuent et ils devront peut-être réduire leurs effectifs, mais pour continuer à développer Firefox, ils ont besoin d’une plus forte participation de la communauté, et GitHub étant la plateforme de développement la plus connue, cela abaisse la barrière à l’entrée. On peut regretter qu’ils n’aient pas choisi GitLab ou autre à la place de GitHub, mais le fait que le développement de Firefox continue et qu’il existe un moteur concurrent sur le marché est bénéfique pour tout le monde
  • Je ne pense pas que les personnes qui renoncent à contribuer parce qu’elles ne peuvent pas utiliser GitHub soient, dans l’ensemble, des contributeurs particulièrement précieux. Il y a sans doute des exceptions, mais je n’en ai jamais vu dans les projets open source non triviaux auxquels j’ai participé directement. Au contraire, je pense qu’une barrière à l’entrée légèrement plus élevée peut avoir l’effet positif de filtrer les contributeurs occasionnels de faible qualité
  • J’ai complètement renoncé à contribuer à Firefox via des patchs parce que je ne comprenais pas la combinaison gh + Phabricator. Je n’ai jamais compris comment les deux s’articulaient, ni comment mettre à jour les branches/PR, donc j’ai fini par abandonner avant même d’essayer
  • D’après mon expérience personnelle avec GitLab, il est apparu clairement il y a quelques années que GitLab n’avait pas beaucoup d’intérêt pour l’hébergement de grands projets open source, et que le seul moyen pour les projets FOSS d’y être pris en charge passait par leur programme open source. Ce processus est complexe et comporte de nombreuses exigences supplémentaires, ce qui serait difficilement acceptable pour Mozilla. Par exemple, pour utiliser GitLab, le projet open source concerné doit renoncer au droit de modifier/forker la version GitLab FOSS, ce qui est un problème sérieux pour n’importe quel projet. C’est peut-être juste un juriste qui a ajouté une clause standard, mais cela suffit déjà à montrer qu’il y a un gros problème. Donc GitLab est écarté. Il reste Codeberg et d’autres, mais si l’objectif est de réduire la barrière à l’entrée pour les nouveaux contributeurs, GitHub convient mieux puisque la plupart des gens y sont déjà inscrits
  • Le passage à GitHub est un changement technique, mais le vrai cœur du sujet est le passage de Mercurial à Git, et je suppose que des considérations sociales ont influencé cette décision technique
  • J’estime que les personnes qui ne peuvent pas franchir cette barrière à l’entrée ne devraient pas non plus signaler de bugs, et encore moins modifier le code
• C’est bien de voir qu’ils ont réglé une dette technique majeure pour contribuer à Firefox. Quand j’ai essayé il y a quelques années, Mercurial mettait des heures à cloner le dépôt, et comme il n’y avait pas de support Git officiel, il fallait utiliser un support Git non officiel pour travailler correctement. À l’époque, la documentation était aussi catastrophique et faisait tout recompiler inutilement
• Je me demande pourquoi ils ont choisi l’org mozilla-firefox plutôt que l’org mozilla existante
  • Sans doute parce que les règles d’accès sont différentes, ou parce qu’ils voulaient isoler cela de l’org existante pour éviter que l’automatisation n’impacte d’autres éléments
  • Je pense que c’est une très bonne question
• Je me demande quelle est la source de « Firefox Moves to GitHub ». Ce n’est peut-être qu’un miroir. Linux a aussi un miroir sur GitHub. (Édition ultérieure : source ajoutée)
  • J’ai eu la même réaction. En pratique, le workflow configuré sur GitHub consiste uniquement à fermer les PR avec une réponse standard
• Firefox Mobile (Fenix) utilisait autrefois GitHub, puis a récemment migré vers le dépôt Mercurial mozilla-central de Mozilla ; désormais, les versions desktop et mobile sont toutes les deux sur GitHub, tandis que les tickets restent sur Bugzilla. On profite ainsi de la bonne recherche de GitHub, de la navigation dans le code et de la familiarité avec Git. En tant qu’ancien contributeur à Firefox et Thunderbird, j’utilisais bien plus souvent la recherche locale que la recherche sur le site mozilla-central. Pendant le développement, on cherche dans l’IDE, mais une recherche simple sur le site est un point positif appréciable pour les nouveaux contributeurs
  • À l’inverse, je pense que searchfox est le meilleur outil de navigation dans le code que j’aie jamais utilisé. Il offre beaucoup de fonctionnalités, comme la navigation inter-langages et le blame toujours activé, et il est bien plus rapide et léger que GitHub. J’aimerais que davantage de projets puissent utiliser ce genre d’outil, et sa disparition serait regrettable
  • J’ai l’impression que la qualité de la navigation dans le code sur GitHub s’est sérieusement dégradée récemment. Chargement asynchrone (JS requis), cassures quand le réseau est instable, recherche dans la page qui ne fonctionne plus. Je trouve aussi que la récente refonte des issues/PR est une régression, et avec uBlock Origin il est impossible de faire des recherches dans les PR
• Je pense que c’est une bonne évolution, mais je me demande pourquoi ils ont créé une nouvelle org au lieu d’utiliser l’org existante github.com/mozilla
  • Je ne connais pas la raison exacte, mais dans plusieurs cas il faut segmenter par org ; par exemple, le SSO ne s’applique qu’à l’échelle d’une org entière, donc les dépôts Firefox peuvent avoir une configuration d’authentification/utilisateurs complètement différente de celle des dépôts principaux de Mozilla
  • Mozilla a plusieurs orgs
  • J’imagine que c’est à cause de la loi de Conway
  • GitHub ne propose qu’un niveau org ou repo, sans niveau supérieur. Beaucoup de paramètres (SSO, droits d’accès, paramètres communs, etc.) s’appliquent par org, donc créer une nouvelle org est souvent la solution la plus propre, même si c’est aussi contraignant (avec GitLab, on aurait pu avoir des namespaces Firefox et autres dans une même instance ou org)
• Je trouve étrange qu’une organisation comme Mozilla utilise un hébergement externe comme GitHub. Je comprends pour un petit projet maintenu par une seule personne, mais imposer aux contributeurs un compte sur un service externe n’est pas très accueillant
  • Pour un projet open source, je pense que c’est positif, car cela offre à tout le monde un environnement ouvert, plus facile pour contribuer, et une meilleure visibilité
• Si je me souviens bien, la branche « master » correspondait à mozilla-central. Maintenant il y a « main » et « autoland » ; je me demande ce que c’est et quelle branche est l’équivalent de l’ancien mozilla-central
  • Je ne suis pas développeur Firefox, mais « main » semble correspondre à mozilla-central, et « autoland » est une branche qui existait déjà à côté auparavant, là où les commits arrivent d’abord
• J’espère que Bugzilla restera disponible, même en lecture seule. Le Web est une plateforme construite de manière « ad hoc », et beaucoup de raisons historiques ne subsistent que dans Bugzilla. C’est souvent le seul endroit où l’on peut encore comprendre pourquoi des sites ou navigateurs disparus se comportaient d’une certaine manière
  • Bugzilla reste bien le bug tracker de Firefox. Il n’y a aucun projet de changement. (Les issues GitHub ne sont pas utilisées)
  • Bugzilla était excellent et en avance sur son temps. Je pense qu’il n’existe toujours pas aujourd’hui de bug tracker auto-hébergé du même niveau