2 puntos por GN⁺ 12 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En 2008, Emacs evaluó Git y Bazaar como candidatos para reemplazar CVS, y en los benchmarks Git fue abrumadoramente más rápido
  • Richard Stallman confirmó la elección de Bazaar porque era un paquete GNU, y la discusión técnica no cambió la decisión
  • Mientras GitHub crecía entre 2008 y 2012, los colaboradores de Emacs tuvieron que aprender Bazaar, y Canonical despidió al equipo de desarrollo en 2012
  • En 2013, el estancamiento del mantenimiento de Bazaar y un bug de la rama ELPA reactivaron la discusión, y ELPA finalmente se pasó a Git
  • En 2014, tras el trabajo de migración de Eric S. Raymond, Emacs se movió a Git, pero justo después quedó en evidencia que colaboradores clave tenían problemas para aprender Git

2008: Git era más rápido, pero se eligió Bazaar

  • En marzo de 2008, Emacs quería pasar de CVS a una herramienta de control de versiones más moderna, y los candidatos quedaron reducidos a Git y Bazaar
    • Git era la herramienta creada por Linus Torvalds para el kernel de Linux
    • Bazaar era un proyecto GNU mantenido por Canonical
  • En emacs-devel hubo una discusión de 236 mensajes, y varios desarrolladores hicieron benchmarks de ambas herramientas
    • Andreas Schwab evaluó que bzr log tardaba más de 1 minuto en arrancar y era “tan lento que resultaba completamente inutilizable”
    • David Kastrup observó que git log se ejecutaba casi de inmediato, mientras que Bazaar parecía que debería ser más rápido porque recibía explícitamente la información de copias, movimientos y cambios de nombre de archivos
  • También en las cifras concretas la ventaja de Git era evidente
    • git log | head -1 tardaba 0.012 segundos, mientras que la ejecución equivalente en Bazaar tardaba 21.5 segundos
    • Un commit con cambio de un solo archivo tardaba 0.08 segundos en Git y 17 segundos en Bazaar
  • El entonces mantenedor principal Stefan Monnier consideraba que no era esencial si Bazaar era más rápido o más lento que Git, pero que para que Emacs hiciera la transición tenía que ser “lo bastante rápido”, y al menos bzr diff no debía tardar más de unos pocos segundos
  • El desarrollador de Bazaar en Canonical Jonathan Lange propuso un procedimiento combinando wget, tar, bzr init-repo, bzr branch, bzr pull --remember para el checkout inicial
    • Ese procedimiento era largo y manual en contraste con git clone

La decisión de que había que usar una herramienta GNU

  • Alguien preguntó a los mantenedores y responsables de decisión de Emacs qué información adicional hacía falta para convencerlos de que bzr no era la herramienta adecuada en ese momento
  • Richard Stallman respondió que esta elección no era una decisión del momento, sino una decisión de largo plazo, y que era mejor esperar unos meses a que los desarrolladores de Bazaar mejoraran las cosas que tomar una decisión temporal difícil de revertir
  • En otro mensaje, Stallman fue tajante: “Esta cuestión está terminada y decidida. Usaremos GNU Bzr. Porque es un paquete GNU”
  • Frente al cuestionamiento de que los argumentos técnicos quedaban borrados por una decisión política, Stallman respondió que la regla de apoyo mutuo entre paquetes GNU ayudaba a que el sistema GNU en su conjunto funcionara mejor
  • A la pregunta de si no se podía hacer que Git fuera parte del sistema GNU, dijo que Git podía incluirse en el sistema GNU, pero que era poco probable que sus desarrolladores quisieran convertirlo en un paquete GNU
  • Ni los benchmarks de 2008, ni los 236 mensajes, ni el procedimiento rebuscado propuesto por un empleado de Canonical cambiaron el resultado: Emacs eligió Bazaar por ser un paquete GNU

2008~2012: expansión de Git y la carga de usar Bazaar

  • Mientras GitHub nacía en 2008 y crecía rápidamente, los colaboradores de Emacs tuvieron que aprender Bazaar, una herramienta que no usaban en otros lados, para poder enviar parches
  • En emacs-devel aparecían repetidamente hilos sobre problemas con Bazaar
    • “Help me unstick my bzr, please”
    • “Can NOT bzr the emacs repos (may be bzr has a memory leak)”
  • En 2012, Canonical despidió al equipo de desarrollo de Bazaar
  • Después de eso, el estado del mantenimiento de Bazaar se volvió una carga todavía mayor en el proceso de desarrollo de Emacs

2013: estancamiento del mantenimiento y nueva discusión sobre Git

  • En marzo de 2013, un año después de que el desarrollo de Bazaar prácticamente se hubiera detenido, John Wiegley volvió a preguntar si Emacs podía pasarse a Git
    • El desarrollo de Bazaar estaba en la práctica estancado
    • Bugs importantes que afectaban el desarrollo de Emacs, como los del repositorio ELPA, llevaban años en el bug tracker sin resolverse
  • También en esta discusión hubo alrededor de 200 mensajes
  • La primera reacción de Stallman fue que el mantenedor de Bazaar estaba corrigiendo algunos bugs y que, como él mismo había pedido justo el día anterior una corrección para el bug de la rama ELPA, quería dar un tiempo razonable
  • Dmitry Gutov preguntó si no era demasiado tarde, dado que se trataba de un bug de 1.5 años
  • Stallman dijo que estaba tratando de determinar si Bazaar seguía mantenido de forma efectiva y expresó que quería obtener una respuesta “Yes”
  • Joakim Verona opinó que la comunidad de Bazaar era muy servicial, pero que había muchos bugs y parches conocidos, algunos aportados por desarrolladores de Emacs, que seguían sin entrar upstream incluso después de años
  • Stallman respondió que no tenía tiempo para leer la lista de correo de Bazaar y que la única lista de desarrollo que leía era emacs-devel
  • Ante la pregunta de si los usuarios de Bazaar debían tener voz en la evaluación de si Bazaar estaba suficientemente mantenido, dijo que tomaba en cuenta la información relevante, pero que darle “voz” a los usuarios era inapropiado

La crítica de Karl Fogel y el problema de la delegación

  • Producing Open Source Software, autor Karl Fogel y uno de los primeros desarrolladores de Subversion, criticó la forma de evaluar de Stallman y la falta de delegación
  • Fogel consideraba que, si Stallman no tenía tiempo para observar de cerca la situación del desarrollo de Bazaar, entonces tampoco podía evaluar con competencia si Bazaar seguía siendo una buena elección para Emacs
  • Sostuvo que, si no tenía el tiempo ni la energía mental para hacer esa evaluación, debía delegarla en los mantenedores de Emacs
  • Fogel argumentó que preguntarle a una sola persona por un bug no podía servir como indicador sustituto de la salud del proyecto, y que otras personas del hilo ya habían hecho una investigación más rigurosa
  • Stallman respondió que era porque “hay más en juego que Emacs”
    • La cuestión central era qué señal enviaría a otros paquetes GNU si un proyecto emblemático de GNU abandonaba una herramienta GNU
  • Fogel volvió a pedir que Stallman dedicara el tiempo necesario para evaluar si el estado de mantenimiento de Bazaar justificaba la confianza, o que delegara esa tarea en alguien que sí pudiera hacerlo
  • Stallman respondió solamente que ya tenía un plan y lo estaba ejecutando, sin dar detalles concretos, plazos ni delegación

ELPA se pasó primero a Git

  • En la discusión de 2013, Stefan Monnier dijo que no le importaba demasiado seguir usando Bazaar o cambiar a Git, Monotone, Darcs, Mercurial, OpenCM, Fossil u otras opciones
  • Lo que le importaba de inmediato era sacar la rama ELPA de Bazaar
    • Porque Bazaar no podía manejar correctamente la rama ELPA
  • Leo Liu señaló que la mayoría de los proyectos GNU no usaban Bazaar
  • Consideraba que arreglar bugs de Bazaar podía beneficiar a Bazaar, pero perjudicar al conjunto de GNU
    • La lógica era que, si el 20% del tiempo libre de voluntarios se iba en pelear con Bazaar, el costo era lo bastante alto como para desincentivar la participación en proyectos GNU
  • Más tarde ese año, Stefan Monnier movió a Git la rama ELPA, que estaba rota en Bazaar
    • Había un bug que generaba conflictos durante el checkout y ya no quedaba nadie para corregirlo
    • A Stefan no le gustaba tener un esquema de dos herramientas, Git para ELPA y Bzr para trunk, pero veía que no había otra salida
    • Marcó un límite claro para que este cambio no se ampliara a una discusión sobre las ventajas y desventajas de Git y Bazaar ni sobre migrar trunk a Git
  • Cuando ELPA se pasó a Git, quedó lista la base para la siguiente discusión: “si Git es suficiente para ELPA, ¿por qué no lo sería también para trunk?”

2014: el trabajo de transición de Eric S. Raymond y la migración real

  • En agosto de 2014, Eric S. Raymond ya tenía listos los scripts para convertir el repositorio de Emacs
  • Dijo que todo el trabajo difícil ya estaba hecho y que solo hacían falta unas 8 horas de aviso antes de apretar el botón
  • La migración real ocurrió en noviembre de 2014
  • El 13 de noviembre, ESR envió un mensaje de seis palabras: “Commits are open. Have at it.”
  • Esta transición fue descrita por algunos como heroic
  • Tras los 236 mensajes de 2008, los 200 mensajes de 2013, el mantenimiento de Stefan, los problemas repetidos de Bazaar y el paso por un sistema de control de versiones muerto, Emacs finalmente se pasó a Git

Después de la migración: incluso colaboradores clave tuvieron que aprender Git desde cero

  • En los días posteriores a la transición, quedó claro que muchos de los colaboradores centrales nunca habían usado Git
  • En emacs-devel siguieron apareciendo hilos preguntando cómo usar Git
    • 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” llegó a 124 mensajes
  • Detrás de que personas que llevaban años desarrollando un editor de texto importante tuvieran que hacer preguntas básicas sobre Git estaba el tiempo durante el cual Emacs permaneció en Bazaar mientras el resto del mundo se movía a Git

1 comentarios

 
Opiniones en Lobste.rs
  • trabajar en un proyecto liderado por rms de verdad debe ser para volverse loco

    • ah, ahora me vino el flashback de why-cooperation-with-rms-is-impossible.au
  • De verdad es una historia increíble. Hace mucho vi en alguna universidad una charla donde Mark Shuttleworth explicaba el Bazaar original, y la idea de un sistema de control de versiones distribuido me pareció fascinante
    Después salió la reescritura de bzr y me enganché por completo. Me parecía que tenía mucho más sentido que Git, y le dediqué años al proyecto, participando en la mailing list, creando plugins e incluso intentando reescribir en C el algoritmo de comparación de diferencias de código para hacerlo más rápido
    Al final quedó claro que Git ganó, pero me tomó bastante tiempo aceptarlo

  • Según este resumen, Richard Stallman prohibió que el proyecto Emacs migrara a Git hasta 2013. Luego dice que a fines de 2013 y de 2014 Emacs pasó a Git en dos etapas, pero después de inicios de 2013 ya no se vuelve a mencionar a Stallman
    Había apoyado Bazaar durante años, así que ¿de verdad no publicó ni un solo mensaje en contra en los hilos de la mailing list que vinieron después? ¿O será que en ese intervalo perdió autoridad sobre el proyecto Emacs?
    En el hilo de 2014 enlazado en el texto no vi ningún correo con su nombre, aunque puede que haya habido otros hilos no enlazados. Pensé si sería la época en que Stallman renunció a algo por una polémica, pero no; estaba recordando otra cosa. Según Wikipedia, Stallman dejó la Free Software Foundation en 2019, y ni siquiera había dejado el Proyecto GNU

  • No tengo claro qué hace exactamente que un proyecto sea un proyecto GNU oficial. ¿Es por la licencia? Git y Linux son ambos GPLv2-only, y Bazaar es GPLv2+. ¿Es por la cesión de copyright? ¿Por el hosting del repositorio, del issue tracker, de la mailing list y demás? ¿Por llevar el prefijo “GNU” en el nombre, como una especie de respaldo?
    Está claro que hay alguna distinción importante en algún lado, pero no entiendo bien cuál es ni por qué importa
    Y además está este error recurrente de off-by-one:

    On November 13th, ESR posted a seven-word message:

    Commits are open. Have at it.

    [...]

    Six years of debate, [...] and it ended with seven words.
    Ah, dejaron pasar una oportunidad perfecta para que quedara simétrico

  • Por ahí de 2014 quise hacer algo con mysql, pero pasé todo un día intentando sin éxito solo clonar el repositorio y hacer checkout de una rama de release, y al final me rendí; ahora me da mucho menos vergüenza
    Hasta entonces ya había usado CVS, Subversion y Mercurial durante años, así que pensé que el problema era la red o mi computadora. Antes de leer este texto no sabía que los benchmarks reales de bzr habían sido tan terribles, ni que Canonical usaba tanto bzr aun cuando ya había despedido al equipo de bzr
    Unos años después volví a mysql para hacer otra cosa, y ya se habían pasado a Git; como no me bloqueé antes de siquiera empezar, pude hacer trabajo interesante

    Since I had no interesting books to read today, nor interesting films to watch, I decided to scavenge for the most intriguing content one can find online. I ended up reading the Linux kernel mailing lists, but those discussions seemed to be 18+, so I settled for the comparatively civil emacs-devel.
    Es el mejor descargo de responsabilidad de “no, este texto no fue escrito por IA” que he visto hasta ahora

  • Gran texto. Siempre quise ver cómo se desarrollaba este tipo de drama de mailing lists, pero nunca tuve el valor de meterme yo mismo. La estructura del relato y los extractos están muy bien logrados

  • Resume una historia confusa de manera entretenida. Pero me parece que el título encaja mejor como “The Most Bzr Emacs Saga” que como “The Most Emacs Bzr Saga”
    No es que nunca se use “Emacs” como adjetivo, pero aun así suena raro

  • Bazaar fue el primer sistema de control de versiones que usé. En esa época yo estaba entrando a Linux por medio de Ubuntu, y Canonical usaba Launchpad, donde podías hospedar tu código fuente
    Antes de eso no subía mi código a ningún lado, así que usar Launchpad y Bazaar me parecía bastante genial. Claro, mis proyectos eran tan pequeños que nunca llegué a notar problemas de rendimiento