A saga mais "Emacs" possível do Bzr

• Em 2008, o Emacs avaliou Git e Bazaar como sucessores do CVS, e nos benchmarks o Git foi esmagadoramente mais rápido
• Richard Stallman confirmou a escolha do Bazaar por ele ser um pacote GNU, e a discussão técnica não mudou a decisão
• Enquanto o GitHub crescia entre 2008 e 2012, contribuidores do Emacs tiveram de aprender Bazaar, e a Canonical demitiu a equipe de desenvolvimento em 2012
• Em 2013, a estagnação da manutenção do Bazaar e um bug no branch do ELPA reacenderam a discussão, e o ELPA acabou migrando para o Git
• Em 2014, após o trabalho de migração de Eric S. Raymond, o Emacs mudou para Git, mas logo em seguida ficou claro que até contribuidores centrais tinham dificuldades para aprender Git

---

2008: o Git era mais rápido, mas o Bazaar foi escolhido

• Em março de 2008, o Emacs queria sair do CVS para uma ferramenta de controle de versão mais moderna, e os candidatos foram reduzidos a Git e Bazaar
  • Git era a ferramenta criada por Linus Torvalds para o kernel Linux
  • Bazaar era um projeto GNU mantido pela Canonical
• No emacs-devel, houve uma discussão com 236 mensagens, e vários desenvolvedores fizeram benchmarks das duas ferramentas
  • Andreas Schwab avaliou que o bzr log levava mais de um minuto para iniciar e era “tão lento a ponto de ser completamente inutilizável”
  • David Kastrup observou que, enquanto git log executava quase imediatamente, o Bazaar parecia como se devesse ser mais rápido por receber explicitamente informações sobre cópia, movimentação e renomeação de arquivos
• Nos números reais, a vantagem do Git também era clara
  • git log | head -1 levava 0,012 segundo, enquanto a execução equivalente no Bazaar levava 21,5 segundos
  • Um commit com alteração em um único arquivo levava 0,08 segundo no Git e 17 segundos no Bazaar
• O então mantenedor principal Stefan Monnier considerava que o ponto central não era se o Bazaar era mais rápido ou mais lento que o Git, mas que ele precisava ser “rápido o suficiente” para que o Emacs migrasse, e que ao menos o bzr diff não deveria levar mais do que alguns segundos
• O desenvolvedor do Bazaar na Canonical Jonathan Lange sugeriu um procedimento que combinava wget, tar, bzr init-repo, bzr branch e bzr pull --remember para o checkout inicial
  • Esse procedimento era longo e manual em contraste com um git clone

A decisão de que ferramentas GNU devem ser usadas

• Alguém perguntou aos mantenedores e tomadores de decisão do Emacs que informação adicional seria necessária para convencê-los de que o bzr não era a ferramenta adequada naquele momento
• Richard Stallman respondeu que essa escolha não era uma decisão para o momento atual, mas uma decisão de longo prazo, e que seria melhor esperar alguns meses para que os desenvolvedores do Bazaar melhorassem a situação do que tomar uma decisão temporária difícil de reverter
• Em outra mensagem, Stallman cravou: “Essa questão terminou e foi decidida. Vamos usar GNU Bzr. Porque ele é um pacote GNU”
• Diante da crítica de que argumentos técnicos estavam sendo apagados por uma decisão política, Stallman respondeu com a regra de que pacotes GNU devem apoiar uns aos outros, pois isso faria o sistema GNU como um todo funcionar melhor
• À pergunta “por que não tornar o Git parte do sistema GNU?”, ele disse que o Git poderia ser incluído no sistema GNU, mas achava improvável que os desenvolvedores do Git quisessem transformá-lo em um pacote GNU
• Nem os benchmarks de 2008, nem as 236 mensagens, nem o procedimento alternativo proposto por um funcionário da Canonical mudaram o resultado: o Emacs escolheu o Bazaar por ele ser um pacote GNU

2008–2012: expansão do Git e o peso de usar Bazaar

• Enquanto o GitHub surgia em 2008 e crescia rapidamente, contribuidores do Emacs precisavam aprender Bazaar, uma ferramenta que não usavam em outros lugares, para enviar patches
• No emacs-devel, reapareciam repetidamente threads sobre problemas com o Bazaar
  • “Help me unstick my bzr, please”
  • “Can NOT bzr the emacs repos (may be bzr has a memory leak)”
• Em 2012, a Canonical demitiu a equipe de desenvolvimento do Bazaar
• Depois disso, o estado de manutenção do Bazaar virou um peso ainda maior no processo de desenvolvimento do Emacs

2013: estagnação da manutenção e nova discussão sobre Git

• Em março de 2013, um ano depois de o desenvolvimento do Bazaar ter praticamente parado, John Wiegley perguntou novamente se o Emacs poderia migrar para o Git
  • O desenvolvimento do Bazaar estava praticamente estagnado
  • Bugs importantes que afetavam o desenvolvimento do Emacs, como no repositório ELPA, permaneciam por anos no rastreador de bugs sem solução
• Essa discussão também se estendeu por cerca de 200 mensagens
• A primeira reação de Stallman foi dizer que um mantenedor do Bazaar estava corrigindo alguns bugs, e que ele próprio havia pedido no dia anterior a correção do bug do branch do ELPA, então queria dar um prazo razoável
• Dmitry Gutov perguntou se isso não era tarde demais, já que se tratava de um bug com 1,5 ano de idade
• Stallman disse que estava tentando julgar se o Bazaar ainda era mantido de forma eficaz e declarou que queria obter uma resposta “Sim”
• Joakim Verona comentou que a comunidade do Bazaar era muito prestativa, mas que havia muitos bugs e patches conhecidos, alguns fornecidos por desenvolvedores do Emacs, que ainda não haviam sido incorporados upstream após anos
• Stallman respondeu que não tinha tempo para ler a mailing list do Bazaar e que a única mailing list de desenvolvimento que ele lia era a emacs-devel
• À pergunta se usuários do Bazaar deveriam ter voz na avaliação sobre a suficiência da manutenção do Bazaar, ele respondeu que considerava informações relevantes, mas julgava inadequado dar “voz” aos usuários

A crítica de Karl Fogel e o problema da delegação

• Producing Open Source Software, autor Karl Fogel e um dos primeiros desenvolvedores do Subversion, criticou a forma como Stallman julgava a situação e a ausência de delegação
• Fogel considerava que, se Stallman não tinha tempo para observar com atenção o estado do desenvolvimento do Bazaar, então também seria difícil julgar com competência se ele ainda era uma boa escolha para o Emacs
• Ele defendia que, se não havia tempo nem energia mental para fazer essa avaliação, ela deveria ser delegada aos mantenedores do Emacs
• Fogel argumentou que perguntar a uma única pessoa sobre um único bug não podia servir como indicador substituto da saúde de um projeto, e que outras pessoas na thread já haviam feito uma investigação mais aprofundada
• Stallman respondeu que era porque “há mais em jogo do que o Emacs”
  • A questão central era qual sinal seria enviado a outros pacotes GNU se um projeto representativo do GNU abandonasse uma ferramenta GNU
• Fogel voltou a exigir que Stallman dedicasse tempo suficiente para avaliar a confiabilidade da manutenção do Bazaar, ou delegasse a decisão a alguém que pudesse fazê-lo
• Stallman respondeu apenas que já tinha um plano e que ele estava em execução, sem apresentar detalhes concretos, cronograma ou delegação

O ELPA migra primeiro para o Git

• Na discussão de 2013, Stefan Monnier disse que não se importava muito se continuariam com Bazaar ou se mudariam para Git, Monotone, Darcs, Mercurial, OpenCM, Fossil ou outra ferramenta
• O que importava de imediato para Stefan era tirar o branch do ELPA do Bazaar
  • Isso porque o Bazaar não conseguia lidar corretamente com o branch do ELPA
• Leo Liu observou que a maioria dos projetos GNU não usava Bazaar
• Ele considerava que corrigir bugs do Bazaar podia ser bom para o Bazaar, mas ruim para o GNU como um todo
  • A lógica era que, se 20% do tempo livre de voluntários fosse gasto brigando com o Bazaar, o custo seria alto o bastante para desestimular a participação em projetos GNU
• No fim daquele ano, Stefan Monnier moveu para o Git o branch do ELPA, que estava quebrado no Bazaar
  • Havia um bug que causava conflitos durante o checkout do branch do ELPA, e não restava ninguém para corrigi-lo
  • Stefan não gostava da ideia de manter dois sistemas, Git para o ELPA e Bzr para o trunk, mas via nisso a única saída
  • Ele fez questão de dizer que essa mudança não deveria ser ampliada para um debate sobre os prós e contras de Git e Bazaar nem sobre migrar o trunk para Git
• Com o ELPA no Git, surgiu a base para a discussão seguinte: se o Git era suficiente para o ELPA, por que não seria suficiente também para o trunk?

2014: o trabalho de migração de Eric S. Raymond e a mudança real

• Em agosto de 2014, Eric S. Raymond já tinha prontos os scripts de conversão do repositório do Emacs
• Ele disse que todo o trabalho difícil já havia terminado e que só precisava de cerca de 8 horas de aviso antes de apertar o botão
• A migração de fato aconteceu em novembro de 2014
• Em 13 de novembro, ESR enviou a mensagem de seis palavras “Commits are open. Have at it.”
• Essa conversão foi descrita por alguns como heroic
• Depois das 236 mensagens de 2008, das 200 mensagens de 2013, da manutenção de Stefan, dos repetidos problemas com o Bazaar e de passar por um sistema de controle de versão morto, o Emacs enfim mudou para o Git

Depois da migração: até contribuidores centrais tiveram de aprender Git do zero

• Nos dias logo após a mudança, ficou claro que muitos dos contribuidores centrais nunca haviam usado Git
• No emacs-devel, apareceram várias threads perguntando como 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” chegou a 124 mensagens
• O fato de pessoas que passaram tantos anos desenvolvendo um editor de texto importante fazerem perguntas básicas sobre Git tinha como pano de fundo o tempo em que o Emacs permaneceu no Bazaar enquanto o resto do mundo migrava para o Git

[GN⁺]

Opiniões no Lobste.rs

• Trabalhar em um projeto liderado pelo rms realmente parece enlouquecedor

  • Ah, agora veio um flashback de why-cooperation-with-rms-is-impossible.au

• É uma história realmente impressionante. Há muito tempo, vi em alguma universidade uma apresentação em que Mark Shuttleworth explicava o Bazaar original, e a ideia de um sistema de controle de versão distribuído pareceu muito interessante
  Depois saiu a reescrita do bzr, e eu fiquei completamente fascinado. Parecia fazer muito mais sentido do que o Git, e passei anos dedicado ao projeto, ativo na mailing list, criando plugins e até tentando reescrever em C o algoritmo de diff para deixá-lo mais rápido
  No fim, ficou claro que o Git venceu, mas levei bastante tempo para aceitar isso

• Segundo este resumo, Richard Stallman teria proibido a migração do projeto Emacs para Git até 2013. Depois diz que, no fim de 2013 e no fim de 2014, o Emacs migrou em duas etapas para o Git, mas Stallman não é mais mencionado depois do começo de 2013
  Ele tinha defendido o Bazaar por anos; será que depois disso realmente não publicou mais mensagens de oposição na mailing list? Ou será que perdeu autoridade sobre o projeto Emacs nesse meio-tempo?
  No thread de 2014 linkado no texto, não vi nenhum e-mail com o nome dele, mas pode ter havido outros threads não linkados. Cheguei a pensar se isso foi na época em que Stallman se demitiu de alguma coisa por causa de uma controvérsia, mas não; eu estava lembrando de outra coisa. Segundo a Wikipedia, Stallman deixou a Free Software Foundation em 2019, e nem sequer deixou o GNU Project

• Não sei exatamente o que faz um projeto se tornar oficialmente um projeto GNU. É por causa da licença? Git e Linux são ambos GPLv2-only, e Bazaar é GPLv2+. É por causa da cessão de copyright? Da hospedagem de repositório, rastreador de issues e mailing list? Do nome com prefixo “GNU”, que funciona como uma espécie de endosso?
  Parece claro que existe alguma distinção importante, mas não entendo bem qual é nem por que ela importa
  E também há o erro recorrente 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, perderam uma oportunidade perfeita de manter a simetria

  • Está falando de software explicitamente incluído sob o guarda-chuva do GNU. Aqui está a lista: https://www.gnu.org/software/software.html#allgnupkgs
  • Quantas vezes a letra a aparece em “bazaar”? :)

• Por volta de 2014, tentei mexer em algo no mysql, mas passei o dia inteiro falhando só para clonar o repositório e fazer checkout da branch de release, e acabei desistindo; isso agora parece bem menos vergonhoso
  Até então eu já tinha usado CVS, Subversion e Mercurial por anos, então achei que o problema era a rede ou o meu computador. Antes de ler este texto, eu não sabia que os benchmarks reais do bzr eram tão terríveis, nem que a Canonical, mesmo usando tanto o bzr, já tinha demitido a equipe do bzr
  Alguns anos depois, quando fui trabalhar em outra coisa no mysql, ele já tinha migrado para Git, e o fato de eu não ter sido bloqueado antes mesmo de começar me permitiu fazer um trabalho interessante

  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.
  É a melhor isenção de responsabilidade de “não, este texto não foi escrito por IA” que já vi

• Ótimo texto. Eu sempre quis ver como esse tipo de drama de mailing list se desenrolava, mas nunca tive coragem de entrar no meio. A construção da narrativa e os trechos escolhidos estão muito bons

• Organiza bem uma história confusa de um jeito divertido. Só acho que o título faria mais sentido como “The Most Bzr Emacs Saga” do que “The Most Emacs Bzr Saga”
  Não que “Emacs” nunca seja usado como adjetivo, mas ainda assim soa meio estranho

• Bazaar foi o primeiro sistema de controle de versão que usei. Na época eu estava entrando no mundo Linux com Ubuntu, e a Canonical usava o Launchpad, onde dava para hospedar código-fonte
  Até então eu nunca tinha publicado código em lugar nenhum, então usar Launchpad e Bazaar parecia bem legal. Claro que meus projetos eram pequenos demais para que eu notasse qualquer problema de desempenho