1 ano depois que o Guix migrou para o Codeberg

 (guix.gnu.org)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Guix mudou em 2025 para o Codeberg o modelo de colaboração que por mais de 10 anos funcionava com Savannah e Debbugs baseado em e-mail, alterando bastante a porta de entrada para contribuições de um projeto com mais de 400 participantes por ano
  • A mudança foi o primeiro caso prático do processo de Guix Consensus Document introduzido em dezembro de 2024, e o GCD 002 entrou em vigor no início de maio de 2025 após dois meses de discussão
  • O fluxo de trabalho anterior por e-mail era eficiente para usuários experientes graças a ferramentas como Emacs, mumi e qa.guix.gnu.org, mas em uma pesquisa com 900 respostas foi frequentemente apontado como uma barreira para contribuidores
  • Depois da migração para o Codeberg, o número de autores e de novos autores aumentou, mas, tirando o pico temporário de junho de 2025, é difícil confirmar um efeito Codeberg claro
  • Mais de 500 pull requests são abertos por mês e o backlog está crescendo, então reduzir a lacuna de CI, a exigência de assinatura e a carga de revisão continua sendo a próxima tarefa prática do Guix

Da colaboração baseada em e-mail para o Codeberg

  • Em 2025, o Guix migrou para o Codeberg a hospedagem do código-fonte, o rastreamento de issues e os pull requests
    • Antes disso, o código ficou hospedado por mais de 10 anos no Savannah
    • Relatórios de bugs e patches eram tratados por e-mail e rastreados por uma instância do Debbugs
    • Como é um projeto em que mais de 400 pessoas contribuem com código por ano, a própria transição já foi uma grande mudança
  • Os principais contribuidores antigos estavam acostumados ao fluxo de trabalho por e-mail e trabalhavam com eficiência usando o pacote Debbugs para Emacs ou clientes de e-mail avançados
    • Enquanto o Debbugs depende de algumas centenas de linhas de Perl e de padrões de e-mail e estrutura federada, forges web como o Forgejo são sistemas maiores com muitas dependências em Go
  • Em torno do fluxo por e-mail, já existiam também ferramentas auxiliares estabelecidas
    • O mumi fornece uma interface web para o Debbugs
    • O Quality Assurance service aplica automaticamente séries de patches enviados por e-mail em branches Git e compila os pacotes nessas branches
  • Na primeira pesquisa pública com usuários e contribuidores, divulgada em janeiro de 2025, mais de 900 pessoas responderam, e os contribuidores frequentemente apontaram o fluxo por e-mail como uma barreira para contribuir

Uma decisão baseada em consenso conduzida pelo GCD 002

  • O Guix não tinha um “benevolent dictator” para tomar decisões, e em dezembro de 2024 introduziu o processo de Guix Consensus Document
  • O processo GCD busca construir consenso em vez de apenas votar
    • Quem propõe precisa ajustar a proposta junto com os participantes
    • Em vez de simplesmente se opor, os participantes devem sugerir suas necessidades e mudanças concretas para refletir isso
    • Na versão final, as posições são marcadas como support, accept e disapprove
  • O GCD 002 foi submetido em fevereiro de 2025 como proposta para migrar ao Codeberg
    • A discussão durou os dois meses máximos previstos pelo processo
    • Dois terços da equipe do Guix participaram da deliberação
    • Entre os participantes, 72% escolheram support e os 28% restantes escolheram accept
    • Não houve disapprove, e a proposta entrou em vigor no início de maio de 2025
  • Alguns membros com longa trajetória de contribuição consideravam um fluxo aparentemente priorizado para a web menos eficiente do que o e-mail e também relutavam em abrir mão de parte da infraestrutura baseada em e-mail
  • A possibilidade de ampliar o contato com a comunidade e melhorar a experiência do desenvolvedor sustentou a mudança
  • A preferência por uma forge baseada em software livre e hospedada pela organização sem fins lucrativos Codeberg e.V. não gerou grande controvérsia e também se alinhava à orientação do Guix

Transição gradual e uma lacuna de CI maior do que o esperado

  • A migração para o Codeberg foi conduzida de forma gradual, conforme o consenso do GCD
    • O repositório principal foi migrado em 25 de maio de 2025
    • O repositório anterior continua como mirror até hoje
    • O rastreador antigo de issues e patches será mantido até 1º de janeiro de 2026
    • Depois disso, issues e pull requests no Codeberg serão o único mecanismo suportado
    • Relatórios de bugs e patches antigos continuam acessíveis online
  • Graças ao plano criado durante a discussão de consenso, houve poucos problemas ou situações inesperadas na transição
  • A qualidade do serviço prestado por funcionários e voluntários do Codeberg e.V. foi boa, e períodos ocasionais de indisponibilidade costumam ser curtos e claramente comunicados
  • Para contribuidores que preferem fluxos fora do navegador, melhorias na interface do Emacs ajudaram
  • O problema que não foi suficientemente previsto foi a integração contínua para pull requests
    • O recurso do qa.guix.gnu.org que compilava patches enviados por e-mail não foi portado para o Codeberg
    • Durante alguns meses, revisores tiveram de verificar manualmente se os pull requests não causavam problemas, algo que não era sustentável
  • Em setembro de 2025, uma instância do Cuirass foi criada em pulls.ci.guix.gnu.org e passou a compilar pull requests
    • No início, por ter mais limitações que o qa.guix.gnu.org, foi vista como uma solução provisória
    • Hoje, os pacotes são compilados para uma única arquitetura
    • Novos contribuidores podem ver imediatamente nos pull requests os resultados de sucesso ou falha deixados pelo guix-cuirass-bot

O fluxo de contribuições cresceu, mas o backlog também

  • Considerando o número de commits no branch principal de maio de 2024 a maio de 2026, o ritmo de commits do Guix permaneceu constantemente entre “alto” e “muito alto”
  • Como o ritmo de commits sozinho não mostra bem as mudanças, o número mensal de autores de commits, committers e novos autores de commits se torna um indicador mais útil
  • O número mensal de autores e de novos autores continuou aumentando
    • Logo após a migração para o Codeberg, em junho de 2025, houve pico tanto no número de autores quanto no de novos autores
    • Nos demais períodos, o crescimento entre 2025–2026 foi parecido com o de 2024–2025
    • O Guix continua atraindo novos contribuidores, mas não houve um efeito Codeberg muito claro
  • O aumento mensal no número de committers foi mais moderado do que o aumento no número de autores, o que pode indicar que os committers estão processando mais contribuições
  • Os dados de pull requests foram coletados pela API do Forgejo do Codeberg
  • Mais de 500 pull requests são abertos por mês e o ritmo de merge também é alto, mas ainda ligeiramente abaixo da entrada, então o backlog continua crescendo
    • Atualmente, cerca de 639 dos 6.459 pull requests totais estão abertos, algo em torno de 10%
    • Como comparação, no Nixpkgs há cerca de 12 mil pull requests abertos entre 473 mil no total, ou aproximadamente 2,5%
    • O backlog do Guix pode ser resultado de atrito excessivo ou de feedback insuficiente do CI
  • O Guix exige que cada commit receba a assinatura de um committer aprovado
    • Não é como em muitos projetos, incluindo o Nixpkgs, onde basta apertar o botão Merge
    • Quem faz o merge é responsável por aplicar e assinar a mudança
    • O Guix escolheu a segurança da cadeia de suprimentos de software entre a conveniência do desenvolvedor e a segurança do usuário
    • Ainda não está claro se esse custo poderá ser reduzido

Colaboração mais visível no Codeberg

  • Depois da migração para o Codeberg, a atividade do projeto ficou mais visível
  • Os resultados de CI aparecem diretamente nos pull requests, então os contribuidores podem conferir isso de imediato
  • As equipes do Guix são implementadas como equipes no Codeberg
    • O escopo de cada equipe está definido no arquivo CODEOWNERS
    • Os responsáveis por aquela área são chamados automaticamente
    • Um bot aplica labels como team-python, permitindo filtrar issues e pull requests por label
  • O problema de a equipe não receber notificações em issues com essa label continua sendo um incômodo
  • Recursos como referência cruzada entre issues e pull requests e milestones também parecem ajudar na colaboração

Desafios de infraestrutura restantes e a relação com o Codeberg

  • A infraestrutura do Guix ainda precisa de mais ajuda
    • É preciso melhorar o desempenho de build do pulls.ci.guix.gnu.org
    • Também seria bom conseguir compilar para arquiteturas que não sejam x86
    • O Cuirass tem várias limitações, e algumas estão sendo resolvidas na futura série 1.4.x
    • O pulls.ci.guix.gnu.org ainda é focado em pacotes, e seria desejável poder executar também testes de sistema quando apropriado
  • O workflow dos mantenedores de pacotes também ainda pode melhorar
  • O Guix precisa evitar sobrecarregar os servidores do Codeberg e também monitorar o uso de armazenamento do repositório
  • Como solução, existe a opção de exigir que novos contribuidores usem o workflow AGit para criar pull requests
    • O AGit já é popular entre contribuidores do Guix
    • Ainda assim, para algumas pessoas ele parece um “downgrade” em relação ao workflow geral e familiar de pull requests
    • Como no caso do Gentoo, adicionar um ícone “AGit fork” poderia melhorar a descoberta
  • A Guix Foundation votou para se tornar membro apoiador do Codeberg e.V. como forma de agradecimento e apoio
  • Foi enviado um pull request para adicionar o Forgejo e o serviço para configurá-lo no Guix
    • A direção é tornar possível, dentro do próprio Guix, uma implantação declarativa da forge e reproduzível

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Lobste.rs

  • Ver as métricas reais do projeto relacionadas à migração para o Codeberg é bem interessante. Pessoalmente, tenho motivos demais para sair do GitHub, então espero que o Codeberg se torne o novo GitHub, mas eu migrei para meu próprio servidor Forgejo e agora uso o Codeberg como destino de backup de todos os repositórios

    • Entendo que foi dito com boa intenção, mas acho melhor ter vários forges independentes se comunicando entre si via ForgeFed, em vez de tudo se concentrar no Codeberg
      Não precisamos de outro novo hub central de código aberto
    • No momento, não acho que o Forgejo esteja maduro o suficiente para dar conta desse papel. O pessoal do Codeberg está fazendo o que pode, e espero que melhore, mas acho que vai levar tempo
    • No meu caso, acabei migrando tudo para o Fossil, e para as coisas que quero publicar para outras pessoas, montei meu próprio servidor Fossil
      Até agora tem sido ótimo, e com certeza prefiro ao git. Pelos padrões de hoje, a barreira também não é tão alta assim

  • O que realmente me irritou desde que comecei a usar o Codeberg é que quase não existem ferramentas com suporte decente à integração com git, e na prática a maioria é voltada só para GitHub / GitLab

    • Como usuário do magit forge, dá vontade de chorar

  • Não entendi a parte de manter o antigo rastreador de issues e patches até 1º de janeiro de 2026 e depois passar a oferecer suporte apenas a issues e pull requests do Codeberg
    Se uma parte considerável dos contribuidores não gosta do novo fluxo, não entendo por que forçar a mudança, e também fico curioso sobre quais seriam os custos ocultos de permitir vários fluxos. Fico me perguntando por que impor o mesmo método para todo mundo
    É uma implicância pequena, mas não parecia que o Codeberg tinha vários funcionários pagos; até onde eu sabia, era só uma pessoa. Correção: disseram que um segundo funcionário foi contratado em dezembro do ano passado