El repositorio de código de Mozilla Firefox se muda de Mercurial a GitHub

• Firefox movió recientemente su repositorio principal de Mercurial a GitHub
• El seguimiento de errores sigue en Bugzilla, las revisiones de código en Phabricator y el CI en Taskcluster
• Actualmente GitHub es el repositorio central, pero el servidor de Mercurial se mantiene sincronizado desde GitHub, y los sistemas de automatización existentes también migrarán gradualmente a Git
• El repositorio try para pruebas de CI sigue basado en Mercurial, pero cada vez está más oculto detrás de una capa de abstracción y en el futuro será trasladado a Git
• Al poder usar Git como base, los nuevos contribuidores ya no necesitan aprender Mercurial por separado; basta con dominar Git
  • Antes era necesario instalar una extensión llamada git cinnabar, pero ahora basta con usar Git estándar
• El antiguo mozilla-central de Mercurial cambia en Git a la rama main, y la rama autoland se mantiene como autoland también en Git
• El flujo de trabajo basado en PR de GitHub no se ha adoptado por ahora y no forma parte de este cambio. La posibilidad queda abierta a futuro, pero no existe un plan oficial
• Mozilla puede reducir la carga de operar su propia infraestructura de VCS con la transición a GitHub
• El objetivo principal es reducir el costo y la complejidad de ofrecer por cuenta propia el nivel de rendimiento, estabilidad y disponibilidad que exige un proyecto de gran escala

Historial detallado y explicación escritos por Glandium, autor de git-cinnabar: How I (kind of) killed Mercurial at Mozilla

> Mozilla cierra la era de Mercurial al cambiar el repositorio de código de Firefox a GitHub

• Mozilla decidió cambiar el VCS central del desarrollo de Firefox de Mercurial a Git y adoptar GitHub como repositorio oficial
• Esta decisión se apoyó en el desarrollo y la adopción a largo plazo de una herramienta de extensión llamada git-cinnabar, que permitió a los usuarios de Git acceder sin fricción a repositorios de Mercurial
• Los problemas con la estructura de ramas de Mercurial, el crecimiento del tamaño del repositorio y la carga de operar servidores propios se combinaron, haciendo que mantener la infraestructura interna fuera cada vez más difícil
• Aunque la elección de GitHub genera debate, fue una decisión difícil de evitar en términos de practicidad y facilidad para contribuidores, ya que miles de repositorios internos de Mozilla ya existen en GitHub
• git-cinnabar comenzó como un proyecto personal paralelo surgido de necesidades internas de Mozilla, pero es muy probable que siga siendo una herramienta importante durante la transición
  > “No fui yo quien inició el incendio, pero sí es cierto que le eché gasolina.”

[GN⁺]

Comentarios de Hacker News

• Trabajo en Mozilla, pero no estuve involucrado en las herramientas de VCS ni en esta transición; comparto algo de contexto adicional. El repositorio oficial del código de Firefox se movió recientemente de mercurial en hg.mozilla.org a GitHub. Esto solo afecta al código: el seguimiento de issues sigue usando bugzilla, las revisiones de código y el landing siguen en phabricator, y el CI continúa en el sistema taskcluster. A corto plazo, el servidor de mercurial sigue sincronizado desde GitHub para que los sistemas automatizados puedan migrar gradualmente a un backend de git. mercurial todavía se usa para el repositorio “try” (donde se corre CI sobre parches en progreso), pero cada vez queda más oculto detrás de una capa de abstracción, y también se migrará más adelante. Para quienes estaban familiarizados con el repositorio anterior, “mozilla-central” se mapea al nombre de rama estándar de git, “main”, y “autoland” se mapea a la rama “autoland”. Antes ya se podía contribuir a Firefox usando solo git, pero requería instalar una extensión llamada git cinnabar. Tener que elegir entre aprender hg o usar git+extensión era una barrera de entrada para nuevos contribuidores, ya que la mayoría conocía git pero no mercurial. Ahora ya no hace falta pensarlo. El autor de git cinnabar, glandium, escribió en su blog un contexto detallado y las razones al momento del anuncio de la migración. En el corto plazo, desde la perspectiva del contribuidor, casi no cambia nada. El uso normal de git pasó a ser el flujo de trabajo predeterminado y, fuera de eso, nada ha cambiado. En el futuro podría haber soporte para un flujo de trabajo basado en GitHub PR, pero no forma parte de este cambio. En el backend, una vez terminada la migración, Mozilla podrá reducir el tiempo y esfuerzo que implica operar su propia infraestructura de VCS, y cumplir con el rendimiento y la disponibilidad que exige un proyecto tan grande es un reto considerable
  • En lo personal, no creo que haya sido correcta la decisión de Mozilla de mudarse a una plataforma cerrada propiedad de Microsoft
  • Me pregunto si hay un plan para reemplazar Phabricator ahora que fue descontinuado; quisiera saber si están considerando algo como Phorge
  • Gracias por el contexto adicional. Me da curiosidad cuáles eran los principales problemas de escala que enfrentaban con una solución autoalojada
  • Quisiera preguntar si GeckoView y Mozilla Android Components también se moverán a GitHub
  • Lamento que solo el código se haya movido a GitHub y que el seguimiento de issues siga en bugzilla. Una de las principales ventajas de usar GitHub es que mucha gente ya tiene cuenta y conoce la plataforma, pero si los issues solo se reciben en bugzilla, eso también crea una barrera para reportar bugs. He usado bugzilla y Firefox para reportar un bug de accesibilidad en macOS, y fue bastante incómodo porque tuve que encontrar el sitio, registrarme y aprender a usarlo. Al final el bug fue confirmado, pero no se corrigió
• Desde la perspectiva estratégica de Mozilla, parece una decisión comprensible. Puede que sus ingresos desde Google disminuyan y quizá también deban reducir personal, pero si quieren seguir desarrollando Firefox, necesitan más participación de la comunidad, y como GitHub es la plataforma para desarrolladores más conocida, baja la barrera de entrada. Uno puede quejarse de que no usen GitLab u otra alternativa en lugar de GitHub, pero que el desarrollo de Firefox continúe y que exista un motor competidor en el mercado beneficia a todos
  • No creo que la gente que renuncia a contribuir porque no puede usar GitHub sea, en su mayoría, especialmente valiosa como contribuidora. Puede haber excepciones, pero no lo he visto en proyectos open source no triviales en los que participé directamente. De hecho, creo que subir un poco la barrera de entrada puede tener el efecto positivo de filtrar a contribuidores ocasionales y de baja calidad
  • Nunca entendí la combinación de gh y phabricator, así que terminé abandonando por completo la idea de contribuir a Firefox con un patch. No entendí cómo se integraban entre sí ni cómo debía actualizar branches/PR, así que al final dejé de intentarlo
  • En mi experiencia personal con GitLab, hace algunos años GitLab dejó bastante claro que no tenía mucho interés en alojar grandes proyectos open source, y que el soporte para FOSS solo era posible mediante su programa para open source. Ese proceso es complejo y tiene requisitos adicionales, así que sería difícil de aceptar para Mozilla. Por ejemplo, para usar GitLab, el proyecto open source en cuestión tendría que renunciar al derecho de modificar/forkear la versión FOSS de GitLab, y eso es un problema serio para cualquier proyecto. Tal vez algún abogado metió esa cláusula por rutina y así quedó, pero eso por sí solo ya demuestra que es un problema importante. Así que GitLab queda descartado. Quedan Codeberg y otros, pero si se quiere reducir la barrera de entrada para nuevos contribuidores, GitHub encaja porque la mayoría ya está registrada ahí
  • Aunque el cambio a GitHub es un cambio técnico, en realidad el núcleo es el paso de mercurial a git, y supongo que consideraciones sociales influyeron en la decisión técnica
  • Pienso que quien no pueda superar la barrera de entrada ni siquiera debería reportar bugs, y lo mismo aplica para arreglar código
• Qué bueno que hayan resuelto una deuda técnica importante para contribuir a Firefox. Cuando lo intenté hace unos años, mercurial tardaba horas en clonar el repositorio, y como no había soporte oficial para git, había que usar soporte no oficial de git para trabajar bien. En ese momento la documentación también era un desastre y hacía que uno recompilara todo innecesariamente
• Me pregunto por qué eligieron la org mozilla-firefox en vez de la org mozilla existente
  • Tal vez por reglas de acceso distintas, o porque querían separarlo de la org existente para evitar que la automatización afectara otras cosas
  • Me parece una muy buena pregunta
• Me pregunto cuál es la fuente de “Firefox Moves to GitHub”. Podría ser solo un mirror. Linux también tiene un mirror en GitHub. (Editado después: se agregó la fuente)
  • Yo pensé lo mismo. De hecho, el único workflow configurado en GitHub es cerrar PR con una respuesta predeterminada
• Firefox Mobile (Fenix) usaba GitHub antes, pero hace poco migró al repositorio mercurial mozilla-central de Mozilla; ahora tanto las versiones de escritorio como móviles están en GitHub y los issues siguen en bugzilla. Se puede aprovechar la buena búsqueda de GitHub, la navegación del código y la familiaridad de git. Como ex contribuidor de Firefox y Thunderbird, usaba mucho más la búsqueda local que buscar en el sitio de mozilla-central. Durante el desarrollo uno busca desde el IDE, pero tener una búsqueda sencilla en el sitio es algo bienvenido para nuevos contribuidores
  • Yo, en cambio, creo que searchfox es la mejor herramienta de navegación de código que he usado. Tiene navegación entre lenguajes, blame siempre activo y muchas otras funciones; además es mucho más rápida y ligera que GitHub. Ojalá más proyectos pudieran usar herramientas así, y sería una pena que desapareciera
  • Siento que la calidad de la navegación de código en GitHub se ha deteriorado seriamente últimamente. La carga asíncrona (requiere js), se rompe con redes inestables, y la búsqueda dentro de la página también falla. También creo que la reciente renovación de issues/PR fue un retroceso, y con uBlock Origin ni siquiera se puede buscar en PR
• Me parece un buen cambio, pero me pregunto por qué crearon una nueva org en vez de usar la org existente github.com/mozilla
  • No conozco la razón exacta, pero hay casos en que varias cosas deben separarse por org; por ejemplo, SSO solo puede aplicarse a toda la org, así que los repos de Firefox podrían necesitar una configuración de autenticación/usuarios totalmente distinta de los repos principales de Mozilla
  • Mozilla tiene varias orgs
  • Supongo que por la Ley de Conway
  • GitHub solo tiene nivel de org o repo, y nada por encima. Muchas configuraciones (SSO, permisos de acceso, ajustes compartidos, etc.) se aplican por org, así que crear una nueva org suele ser la solución más limpia, aunque también es incómodo (en GitLab se podrían crear namespaces como Firefox y otros dentro de una misma instancia u org)
• Se siente raro que una organización como Mozilla use hosting externo como GitHub. Entiendo que lo haga un proyecto pequeño de una sola persona, pero obligar a los contribuidores a tener cuenta en un servicio externo no parece muy amigable
  • Si es un proyecto open source, creo que es algo positivo porque ofrece visibilidad y un entorno abierto y fácil para contribuir para todo el mundo
• Según recuerdo, la branch “master” era mozilla-central. Ahora están “main” y “autoland”; me pregunto qué son y cuál equivale al antiguo mozilla-central
  • No soy desarrollador de Firefox, pero “main” equivale a mozilla-central y “autoland” es una branch que ya existía antes al lado, donde los commits llegan primero
• Espero que bugzilla siga existiendo aunque sea en modo solo lectura. La web es una plataforma que se fue construyendo de forma “ad-hoc”, y muchas razones del pasado solo quedaron registradas en bugzilla. Incluso por qué sitios web o navegadores ya desaparecidos hacían cierto comportamiento solo se puede verificar ahí
  • bugzilla sigue siendo el bug tracker de Firefox. No hay planes de cambiar eso. (No se usan GitHub issues)
  • bugzilla era excelente y estaba adelantado a su tiempo. Incluso ahora no creo que haya un bug tracker autoalojado del mismo nivel