Repositório de código do Mozilla Firefox migra de Mercurial para GitHub

• O Firefox recentemente migrou seu repositório principal de Mercurial para GitHub
• O rastreamento de bugs continua no Bugzilla, as revisões de código no Phabricator e o CI no Taskcluster
• Atualmente, o GitHub é o repositório central, mas o servidor Mercurial é mantido sincronizado a partir do GitHub, e os sistemas de automação existentes também devem migrar gradualmente para Git
• O repositório try para testes de CI ainda é baseado em Mercurial, mas está sendo cada vez mais ocultado atrás de uma camada de abstração e deve ser migrado para Git no futuro
• Com o Git disponível como padrão, novos contribuidores ganham a vantagem de não precisar aprender Mercurial separadamente, bastando conhecer Git
  • Antes era necessário instalar a extensão git cinnabar, mas agora usar apenas o Git padrão já é suficiente
• O antigo mozilla-central do Mercurial foi renomeado para a branch main no Git, e a branch autoland continua como autoland também no Git
• O fluxo de trabalho baseado em PR do GitHub não foi adotado neste momento e não faz parte desta mudança. Há possibilidade no futuro, mas não existe plano oficial
• Com a transição para o GitHub, a Mozilla pode reduzir a carga de operar sua própria infraestrutura de VCS
• O principal objetivo é reduzir os custos e a complexidade de fornecer internamente desempenho, estabilidade e disponibilidade exigidos por um projeto de grande porte

Histórico detalhado e explicação escritos por Glandium, autor do git-cinnabar: How I (kind of) killed Mercurial at Mozilla

> Mozilla encerra a era do Mercurial ao transferir o repositório de código do Firefox para o GitHub

• A Mozilla decidiu migrar o VCS central do desenvolvimento do Firefox de Mercurial para Git e adotar o GitHub como repositório oficial
• Essa decisão foi sustentada pelo desenvolvimento e pela disseminação de longo prazo da ferramenta de extensão git-cinnabar, que permitia aos usuários de Git acessar repositórios Mercurial de forma fluida
• Problemas na estrutura de branches do Mercurial, o aumento da escala do repositório e o peso de operar servidores próprios se combinaram, fazendo com que as dificuldades de manter a infraestrutura própria se acumulassem
• Houve controvérsia em torno da escolha do GitHub, mas, com milhares de repositórios internos da Mozilla já existentes no GitHub, foi uma escolha praticamente inevitável em termos de facilidade para contribuidores e pragmatismo
• O git-cinnabar começou como um projeto pessoal paralelo motivado por necessidades internas da Mozilla, mas é provável que continue sendo uma ferramenta importante durante o período de transição
  > “Não fui eu quem ateou o fogo, mas é verdade que joguei combustível nele.”

[GN⁺]

Opiniões do Hacker News

• Trabalho na Mozilla, mas não estive envolvido nas ferramentas de VCS nem nesta transição; estou só acrescentando contexto. O repositório oficial do código do Firefox foi movido recentemente do Mercurial em hg.mozilla.org para o GitHub. Isso afeta apenas o código; o rastreamento de issues continua no bugzilla, revisão de código e landing continuam no phabricator, e CI continua no sistema taskcluster. No curto prazo, o servidor Mercurial continua sendo sincronizado a partir do GitHub, para permitir que os sistemas de automação migrem gradualmente para um backend Git. O Mercurial ainda é usado no repositório “try” (onde se roda CI para patches WIP), mas está sendo gradualmente escondido atrás de uma camada de abstração e também deve ser migrado depois. Para quem está acostumado com o repositório antigo, “mozilla-central” foi mapeado para o nome de branch padrão do Git, “main”, e “autoland” para a branch “autoland”. Já era possível contribuir com o Firefox usando apenas Git, mas era necessário instalar uma extensão chamada git cinnabar. Ter que escolher entre aprender hg ou usar Git+extensão era uma barreira de entrada para novos contribuidores, e a maioria conhecia Git, mas não Mercurial. Agora isso não é mais uma preocupação. O autor do git cinnabar, glandium, escreveu no blog dele um contexto detalhado e as razões no anúncio da migração. No curto prazo, do ponto de vista dos contribuidores, quase nada muda. O fluxo de trabalho padrão agora passou a ser o uso normal de Git, e fora isso nada mudou. No futuro pode surgir suporte a um fluxo de trabalho baseado em PRs do GitHub, mas isso não faz parte desta mudança. No backend, quando a migração estiver concluída, a Mozilla poderá reduzir o tempo e o esforço gastos para operar sua própria infraestrutura de VCS, e atender aos requisitos de desempenho e disponibilidade de um projeto desse porte é um desafio considerável
  • Pessoalmente, acho que a Mozilla tomou a decisão errada ao migrar para uma plataforma fechada pertencente à Microsoft
  • Como o Phabricator foi descontinuado, fico curioso para saber se existe um plano de substituição; gostaria de perguntar se estão considerando algo como o Phorge
  • Obrigado pelo contexto extra. Fico curioso sobre quais eram os principais problemas de escala enfrentados na solução self-hosted
  • Gostaria de perguntar se o GeckoView e o Mozilla Android Components também serão movidos para o GitHub
  • Lamento que só o código tenha sido movido para o GitHub, enquanto o rastreamento de issues continua no bugzilla. Uma das principais vantagens de usar o GitHub é que muitos usuários já têm conta e estão familiarizados com a plataforma, mas como as issues só são aceitas no bugzilla, isso também cria uma barreira para relatar bugs. Já usei o bugzilla e o Firefox para reportar um bug de acessibilidade no macOS, e foi bem incômodo ter que achar o site, me cadastrar e aprender a usá-lo. No fim, o bug foi confirmado, mas não corrigido
• Do ponto de vista estratégico da Mozilla, isso parece uma decisão compreensível. A receita vinda do Google pode cair e talvez eles precisem reduzir equipe, mas, para continuar o desenvolvimento do Firefox, é necessário mais envolvimento da comunidade, e como o GitHub é a plataforma de desenvolvimento mais conhecida, a barreira de entrada fica menor. Dá para reclamar do fato de não usarem GitLab ou algo do tipo em vez de GitHub, mas o fato de o desenvolvimento do Firefox continuar e de haver um engine concorrente no mercado beneficia todo mundo
  • Não considero que alguém que desista de contribuir porque não pode usar GitHub seja, na maioria dos casos, um contribuidor particularmente valioso. Pode haver exceções, mas não vi isso em nenhum projeto open source não trivial em que participei diretamente. Pelo contrário, acho que aumentar um pouco a barreira de entrada pode ter o efeito positivo de filtrar contribuidores ocasionais de baixa qualidade
  • Eu não entendia a combinação de gh com phabricator, então desisti completamente de contribuir com patches para o Firefox. Não entendi como os dois se integravam, nem como eu deveria atualizar branch/PR, e no fim acabei desistindo até de tentar
  • Pela minha experiência pessoal com o GitLab, alguns anos atrás ele deixou bem claro que não tinha muito interesse em hospedar grandes projetos open source, e só dava para atender a projetos FOSS por meio do programa open source deles. Esse processo é complexo e envolve exigências adicionais, o que provavelmente seria difícil de aceitar para a Mozilla. Por exemplo, para usar o GitLab, o projeto open source em questão teria que abrir mão do direito de modificar/forkar a versão FOSS do GitLab, e isso é um problema sério para qualquer projeto. Talvez algum advogado tenha colocado isso como cláusula padrão sem pensar muito, mas isso por si só já mostra como é um problema grande. Então o GitLab fica de fora. Restam alternativas como o Codeberg, mas, se a meta é reduzir a barreira de entrada para novos contribuidores, o GitHub é adequado porque a maioria já tem conta lá
  • Embora a ida para o GitHub seja uma mudança técnica, o ponto central real é a migração de Mercurial para Git, e imagino que considerações sociais tenham influenciado a decisão técnica
  • Acho que quem não consegue superar a barreira de entrada não deveria nem reportar bugs, quanto mais enviar correções de código
• É bom ver uma dívida técnica importante nas contribuições ao Firefox sendo resolvida. Quando tentei contribuir alguns anos atrás, o Mercurial levava horas para clonar o repositório, não havia suporte oficial a Git, e era preciso usar suporte não oficial a Git para trabalhar direito. Na época, a documentação também era péssima e fazia você recompilar tudo à toa
• Fico curioso para saber por que escolheram a org mozilla-firefox em vez da org mozilla já existente
  • Talvez por causa de regras de acesso diferentes, ou porque queriam manter separado do org existente para evitar que a automação afetasse outras áreas
  • Acho uma pergunta realmente muito boa
• Fico curioso sobre qual é a fonte de “Firefox Moves to GitHub”. Pode ser apenas um mirror. O Linux também tem mirror no GitHub. (Editado depois: fonte adicionada)
  • Pensei a mesma coisa. Na prática, o fluxo de trabalho configurado no GitHub é só fechar PRs com uma resposta padrão
• O Firefox Mobile (Fenix) usava GitHub no passado, depois foi migrado há pouco tempo para o repositório Mercurial mozilla-central da Mozilla, e agora tanto a versão desktop quanto a mobile estão no GitHub, enquanto as issues continuam no Bugzilla. Dá para aproveitar a boa busca do GitHub, a navegação pelo código e a familiaridade do Git. Como ex-contribuidor do Firefox e do Thunderbird, eu usava muito mais busca local do que a busca no site mozilla-central. Durante o desenvolvimento, você busca pela IDE, mas uma busca fácil no site é algo bem-vindo para novos contribuidores
  • Por outro lado, eu considero o searchfox a melhor ferramenta de navegação de código que já usei. Tem recursos como navegação entre linguagens, blame sempre ativo e muito mais, além de ser bem mais rápido e leve que o GitHub. Seria ótimo se mais projetos pudessem usar essa ferramenta, e eu acharia uma pena se ela desaparecesse
  • Tenho a sensação de que a qualidade da navegação de código no GitHub piorou seriamente nos últimos tempos. Há carregamento assíncrono (exige JS), quebra com rede instável, e até a busca na página deixa de funcionar. Também considero o redesign recente de issues/PRs um retrocesso, e com uBlock Origin não dá para pesquisar PRs
• Acho uma boa mudança, mas fico curioso sobre por que criaram uma nova org em vez de usar a org existente github.com/mozilla
  • Não sei o motivo em detalhe, mas em vários aspectos é preciso separar por org; por exemplo, SSO só pode ser aplicado ao org inteiro, então os repositórios do Firefox podem exigir uma configuração de autenticação/usuários totalmente diferente dos repositórios principais da Mozilla
  • A Mozilla tem várias orgs
  • Imagino que seja por causa da Lei de Conway
  • O GitHub só tem nível de org ou repo, não existe um nível acima disso. Muitas configurações (SSO, permissões de acesso, configurações compartilhadas etc.) são aplicadas por org, então criar uma nova org costuma ser a solução mais limpa, embora também seja inconveniente (no GitLab, seria possível criar namespaces como Firefox e outras coisas dentro de uma única instância ou org)
• Acho estranho uma organização como a Mozilla usar hospedagem externa como o GitHub. Entendo no caso de projetos pequenos de uma pessoa só, mas obrigar contribuidores a terem conta em um serviço externo não parece amigável
  • Se for um projeto open source, acho positivo por oferecer visibilidade, facilidade de contribuição e um ambiente mais aberto para todos
• Pelo que me lembro, a branch “master” era a mozilla-central. Agora existem “main” e “autoland”, e fico curioso sobre o que são e qual delas equivale à antiga mozilla-central
  • Não sou desenvolvedor do Firefox, mas “main” corresponde à mozilla-central, e “autoland” é a branch que já existia ao lado dela, para onde os commits chegam primeiro
• Espero que o bugzilla continue existindo, nem que seja em modo somente leitura. Como a web é uma plataforma construída de forma ad hoc, muitas razões do passado só estão registradas no bugzilla. Motivos pelos quais sites ou navegadores já extintos se comportavam de certo modo só podem ser confirmados ali
  • O bugzilla continua sendo o rastreador de bugs do Firefox. Não há plano de mudar isso. (GitHub Issues não são usadas)
  • O bugzilla era excelente e estava à frente do seu tempo. Ainda hoje acho que não existe um rastreador de bugs self-hosted no mesmo nível