Se eu pudesse criar meu próprio GitHub

 (matduggan.com)
4 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Forges modernas como GitHub, GitLab e Gitea compartilham o modelo ao estilo GitHub, mas no trabalho real o núcleo acontece muito mais dentro de recursos da forge como PRs, Actions, Issues e Releases do que no git
  • Uma nova forge deveria executar remotamente hooks de pre-commit obrigatórios que dão feedback antes do push, e não depois do commit, para reduzir sequências de commits repetidos como Feature, fix, actually fix, asdfasdf
  • A aprovação de PR deveria ir além da dicotomia aprovar/rejeitar e oferecer, como no Gerrit, aprovação fraca e marcação para revisar depois; mudanças pequenas em que o autor é mantenedor e a LLM julga como de baixo risco também deveriam poder passar com mais flexibilidade
  • Stacked PRs deveriam ser um recurso de primeira classe tanto da forge quanto do VCS, e o repositório local deveria representar o estado completo do repositório, incluindo aprovações de PR e issues, não só o código
  • A combinação desejada é JJ como VCS, uma nova forge que possa ser hospedada em unidades pequenas, e Actions com suporte a assinatura, SHA e execução offline; ainda não existe uma alternativa clara numa era em que o GitHub é a opção padrão

Os problemas das forges modernas

  • GitHub, GitLab e Gitea têm diferenças de detalhe, mas seguem quase o mesmo modelo de design, mais como ferramentas que reproduzem o padrão do setor criado pelo GitHub
  • A maior parte dos recursos das forges atuais tem pouca relação direta com o próprio git, e o cliente está desconectado da forma como realmente se usa
  • O git é um sistema distribuído de controle de versão que se encaixa bem em ambientes como o desenvolvimento do kernel, adequado a um fluxo de trabalho baseado em alta confiança, em que patches são enviados por e-mail aos mantenedores, e os mantenedores administram sua área e decidem o que será mesclado
  • Mas na maioria dos locais de trabalho, o git é mais um meio de fazer pull/push de código em repositórios armazenados numa forge central, e o trabalho importante acontece dentro da forge
    • Pull Requests viram um meio de impor o princípio dos quatro olhos
    • GitHub Actions roda testes e linting em Pull Requests para verificar funcionalidade e conformidade com exigências da organização
    • A identidade do usuário dentro da forge vira o critério para validar o usuário
    • Issues são usadas para rastrear problemas de código, e Releases para criar versões que os usuários vão baixar
  • Como esse fluxo de trabalho depende mais dos recursos da forge construídos sobre o git do que do próprio git, ao criar uma nova forge há menos motivo para ficar necessariamente preso à restrição do git

Recursos desejados numa nova forge

  • O feedback deve vir antes do commit, não depois

    • PRs comuns costumam acumular commits como Feature, fix, fix, actually fix, please, asdfasdf
    • Quando o ciclo de feedback vem depois do commit, o usuário acaba sofrendo e corrigindo coisas até tarde da noite
    • A forge deveria oferecer hooks de pre-commit obrigatórios executados remotamente, para que o usuário receba feedback antes de fazer push

  • A aprovação de PR é binária demais

    • Hoje, um PR é tratado como aprovado ou não aprovado, mas a revisão de código real tem muito espaço entre esses extremos
    • Reações humanas como “por enquanto está ok, resolvemos depois” também deveriam poder ser expressas por um botão
    • O Gerrit oferece um modelo melhor nesse ponto
    • Quando um mantenedor aprovar de forma fraca, deveria ser possível marcá-lo para voltar a ver depois

  • A política de PR deveria ser mais flexível

    • Nem toda mudança precisa de revisão por quatro olhos, especialmente num cenário em que existem LLMs
    • O custo de esperar um engenheiro sênior deixar um LGTM num PR de quatro linhas é excessivo
    • Se o autor for mantenedor e a LLM avaliar a mudança como de baixo risco ou sem risco, deveria haver um controle mais fácil para deixá-la seguir direto

  • Stacked PRs deveriam ser recurso de primeira classe

    • Stacked PRs tornam a revisão e a compreensão mais fáceis
    • Isso não deveria ser um extra feito por ferramenta externa ao VCS, mas tratado como cidadão de primeira classe na forge e no VCS

  • A forge não deveria tentar fazer tudo

    • Rastreamento de issues é necessário, mas um quadro Kanban provavelmente não é
    • A necessidade de wiki também é questionável
    • Ferramentas que colocam tudo acabam perdendo qualidade, e embora adicionar recursos seja fácil, o custo de manutenção continua existindo independentemente da taxa de adoção
    • Quando alguém começa a usar esse recurso em algum lugar, você fica preso a ele

  • A unidade de hospedagem é grande demais

    • Operar GitHub Enterprise é um grande trabalho, e operar GitLab também é um peso considerável
    • Esses produtos são sistemas complexos com muitas partes móveis
    • Deveria ser possível criar unidades menores de hospedagem individual e conectá-las para formar uma organização
    • Não precisa ser federação global, e tudo bem se cada organização exigir uma conta; o importante é que uma organização possa ser flexível a ponto de dizer “estas 12 Raspberry Pis são minha organização”

  • O repositório local deveria representar o repositório inteiro, não só o código

    • A cópia local deveria representar o repositório completo, incluindo aprovações de PR e issues, e não apenas o código
    • Deveria ser possível aprovar PRs no mesmo VCS em que se faz check-in do código
    • Deveria ser possível examinar issues como quem percorre arquivos locais

  • Nem sempre é preciso pagar o custo de armazenar o histórico completo

    • Para trabalhar direito em equipe, é preciso estar online, então não é necessário obrigar sempre o custo de armazenar tudo
    • VCS e forge deveriam funcionar juntos
    • Ao fazer clone de um repositório, você receberia apenas um histórico limitado; quando quisesse voltar ao passado, subiria um worker para buscar no VCS o que for necessário
    • Não é preciso continuar enviando pedidos enormes de clone para a forge só porque, em tese, um dia o usuário poderia reconstruí-la com o histórico completo do projeto

  • Actions deveriam ser assinadas, fixadas por SHA e usáveis offline

    • Actions são importantes, então precisam de assinatura, SHA e possibilidade de uso offline
    • Se quiser, deveria ser possível baixar o tarball de toda action, colocá-lo no repositório e instruir o sistema a usar a action de checkout que está no repositório local, sem buscar nada de fora
    • Se latest for especificado, isso deveria funcionar abrindo um PR que coloca no repositório o tarball mais recente, como o Dependabot faz hoje
    • Se quiser, as Actions também deveriam poder ser executadas na máquina local por meio do mesmo VCS

Já existem ferramentas que fazem partes disso, mas falta a combinação

  • Já existem muitas ferramentas que atendem a parte desses requisitos
  • O que falta é pegar essas ferramentas, juntá-las e fazê-las se encaixar de verdade
  • A combinação desejada é JJ como VCS, um novo sistema como forge, e a expectativa de que o usuário possa usar uma única Raspberry Pi como forge por muito tempo e com satisfação
  • A nova forge deveria ser projetada em torno de conceitos modernos como armazenamento de objetos, shallow clone e requisições contínuas de bots de LLM

As rachaduras numa era em que o GitHub é o padrão

  • Se o GitHub estivesse fazendo isso bem, não haveria motivo para escrever essa visão
  • O GitHub é o padrão, e convencer alguém a ir além do padrão costuma ser quase uma perda de tempo
  • Até 2026, se alguém fosse usar uma forge, precisava ter um motivo muito forte para não escolher a ferramenta que todo mundo usa
  • Até recentemente, outras forges eram vistas mais como substitutos do que como opções realmente desejadas
  • Mas a grande forge única está ruindo, e ainda não surgiu uma substituta
  • Quem tem dinheiro está ocupado com foguetes, quem tem gosto está ocupado com o próprio trabalho, e o resto abre um PR chamado asdfasdf à meia-noite, espera a checagem do robô e se pergunta desde quando a ferramenta que usa o dia inteiro deixou de ser feita para o usuário

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • A crítica de que a aprovação de PR é binária demais parece contraditória. Aprovar PR é conceder permissão, então no fim só pode ser booleano: ou dá para fazer merge do código ou não
    O que estão pedindo aqui parece mais um mecanismo para aliviar a consciência ao aprovar um código de que não gostaram, com algo como “precisa revisar de novo depois...”. É só abrir um novo ticket

    • O Gerrit tem notas de -2 a +2
      -2: ideia ruim, não faça
      -1: boa ideia, mas precisa melhorar
      +1: parece bom, mas não tenho conhecimento ou permissão para aprovar
      +2: aprovado
    • Eu queria um botão para dizer: “aprova e faz merge destes 3 commits agora, estes outros 2 precisam ser refeitos”
    • Também existe caso em que o código é aprovado, mas não é feito merge. Aí um mantenedor aplica manualmente com mudanças adicionais e pode colocar o autor do PR como coautor do commit resultante
    • O problema maior me parece ser que o GitHub é separado demais do sistema de rastreamento de issues. Ficar sincronizando tudo manualmente dá muito trabalho, e o Linear ajuda um pouco, mas não é o ideal
    • “Ou dá para fazer merge do código ou não” — claramente não é um intuicionista

  • É verdade que “Y faz parte disso”, mas o tangled.org faz mesmo a maior parte

    1. Usa JJ como sistema de controle de versão: o tangled oferece suporte a PRs empilhados com jj change-id. https://blog.tangled.org/stacking O próprio tangled é muito construído assim: https://tangled.org/tangled.org/core/pulls
    2. Um forge que pode rodar por muito tempo num Raspberry Pi: isso também dá. O shim do servidor git é bem leve, é só uma camada XRPC sobre repositórios git e um banco sqlite3. Tem gente rodando em placa RISC-V com 512MB de RAM
    3. Actions são importantes e precisam poder rodar na máquina local: acho que essa exigência erra um pouco o alvo. Ser hermético, rodar em qualquer lugar e lidar com cross-build normalmente é trabalho do sistema de build. Seria ótimo poder “promover” esses resultados de build para o próprio forge
    • Surpreende ver Raspberry Pi citado para hospedar dados centrais do fluxo de trabalho. Já sofri demais com corrupção de cartão SD; fico curioso se hoje em dia usam drive NVME
    • Sim, isso é trabalho do sistema de build. Mas o problema que as pessoas querem resolver com Actions executáveis localmente na maioria das vezes não é a falha de build em si, e sim a integração como um todo
      YAML, segredos, exatamente quais comandos rodam, como restaurar ferramentas e cache. O sistema de build pode cuidar de parte disso, mas as primitivas oferecidas pelo GHA são muito fracas. No fim vira o problema de executar o sistema inteiro em outro lugar, então esses sistemas acabam sendo muito na base de tentativa e erro
    • Isso, e mais ainda: seria bom expandir a ideia de build hermético para algo que pudesse rodar facilmente localmente ou em qualquer lugar com recurso computacional
      O problema fundamental aqui é que ficar no ciclo de mudanças, commits e chamadas de rede até o CI ficar verde é muito doloroso. A melhor forma de evitar essa repetição é nunca escrever bugs! Brincadeira
    • Tanto o Radicle quanto o Tangled erram o ponto principal. Eles são para colaboração pública, mas e os repositórios privados? Muita gente faz projeto paralelo e usa o GitHub private para isso
      Se a pessoa aprende GitHub, acaba começando os projetos públicos lá também. Sem permitir repositórios privados para side projects, vai ser difícil ter adoção ampla. O que as pessoas querem é criar um repositório privado, sumir por alguns meses e voltar, e ele ainda estar lá esperando
    • Uau, o suporte a jujutsu do Tangled é exatamente o que eu estava procurando. Meu fim de semana vai desaparecer montando uma instalação self-hosted

  • Se você quer clonar só um histórico limitado e buscar dados antigos quando precisar, use blobless clone
    git clone --filter=blob:none
    Traz o histórico, e os blobs só quando forem necessários. O GitHub tem um bom texto sobre isso: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Quando a solução vira problema, abre-se espaço para inovação disruptiva. Tem se falado bastante disso ultimamente, e fico curioso para ver se alguma das várias alternativas novas vai ganhar tração antes de o GitHub corrigir o rumo

    • Acho que o problema é que a Microsoft fez all-in em IA. Não tem volta, e o GitHub inevitavelmente vai sofrer esse impacto
      O marketing da Microsoft vai dizer que IA resolve tudo, mas na prática os mesmos problemas vão continuar voltando. As quedas do GitHub podem não ter relação direta com IA, mas como a estratégia da Microsoft já mudou, a maioria das decisões vai ser alinhada a um controle centralizado orientado por IA. Se o fluxo de trabalho de quem usa GitHub quebra ou não, para a Microsoft isso no máximo é preocupação secundária, então esse problema vai continuar reaparecendo. Pode ficar quieto por uns 3 meses, mas eu apostaria 100% que logo vai sair mais um drama novo sobre o declínio do GitHub. O Ghostty não vai ser o último. Vai ser interessante ver se surgem alternativas, mas elas não podem ser ruins, e muitos sites são bem ruins
    • Estou construindo minhas próprias ferramentas. Acho que as pessoas também deveriam construir as próprias ferramentas
      Talvez no futuro, em vez de software pago ou open source, a gente receba um pacote de documentos de requisitos para um forge de código, uma espécie de receita. Cada um assa o seu e adapta ao próprio uso e gosto

  • Acho que existe espaço no mercado para um serviço git muito mais simples. Tudo o que preciso é de um host remoto para dar push no projeto e permitir que outras pessoas vejam; não faço muita questão de PR ou Actions
    Seria legal ter ao menos uma função de “releases” para subir assets binários gerados localmente. Forks poderiam ser resolvidos com as pessoas clonando o repositório e publicando como projeto novo

    • Não dá para resolver boa parte disso desligando os recursos de que você não precisa? Acabei de olhar minha instância do Forgejo e há opções por repositório para desativar Code, Projects, Releases, Packages, Actions, Issues, PRs e Wikis
    • https://sr.ht/
    • Então estamos voltando para o cgit?

  • O argumento de que os dados de review também podem ficar em um repositório git como o código-fonte é bem convincente
    Daria para implementar isso muito facilmente colocando um branch por review com um prefixo conhecido, mas o namespace padrão de branches ficaria logo uma bagunça. Você poderia separar do namespace principal com git namespaces, ou ter um branch especial tipo .reviews contendo só os IDs de commit finais de cada branch de review. Se alguém se interessar o suficiente para criar uma especificação e uma implementação realmente utilizável, talvez o pessoal comece a adotar. Minha suspeita é que GitHub e vários forges não seguiram esse caminho porque prender os metadados de review ao próprio ecossistema aumenta o valor da plataforma. Se qualquer um pudesse revisar código alheio com a ferramenta local que quisesse, haveria menos vendor lock-in. Claro, também pode haver outros motivos para querer os metadados de review em outro repositório, como controle de acesso ou reviews entre repositórios

  • Gosto muito do fluxo de trabalho do Gerrit, que revisa diferenças em vez de PRs. Mas, comparado com algo como gitea, ele parece difícil de vender para muita gente por faltar o restante das funções que se espera hoje de uma hospedagem git, como issues e planejamento de projeto
    Seria ótimo ter uma plataforma boa de revisão de diffs como o Phabricator, pena que faz falta

    • Mas então por que a Gitea não adiciona isso? Ela já tem todo o resto; não entendo por que esses forges sempre ficam presos em ser clones do GitHub em vez de ir além

  • Acho que o formato-base para armazenar todas as mensagens, como PRs, comentários de review e issues, deveria ser RFC2822, e na hora de exibir bastaria decorar com CommonMark
    Todos os metadados iriam nos headers, e seria possível encadear tudo com Message-ID/In-Reply-To/References. Com um formato bem definido assim, você pode escolher como armazenar e transportar todas as mensagens: dentro de um repositório git, por email ou de outro jeito que faça sentido. Em revisão de código, pessoalmente acho o Gerrit muito melhor que GitHub e afins. CI eu deixaria o máximo possível do lado de fora, com só alguns hooks para iniciar pipelines, mostrar resultados e decidir se o merge é permitido

    • Acho que um dos atrativos do GitHub é justamente integrar revisão de código, navegação de código-fonte, rastreamento de tickets e CI
      Ele não é excepcional em nenhuma das quatro coisas, mas faz bem o trabalho de juntá-las. Concordo que o Gerrit tem um modelo de revisão melhor, mas sem as outras três peças isso não vira produto. Mesmo quando eu usava Gerrit todo dia no Google, eu me incomodava com a integração fraca entre busca de código, revisão de código e CI. Ferramentas internas do Google como Google3/Critique/Forge costuravam tudo isso muito melhor

  • Lembrei de uma vantagem do fluxo baseado em email. Se você começou a olhar email, normalmente está no estado mental para isso, e nesse estado espera não ter outras distrações, então consegue focar melhor
    O problema das notificações é que elas criam um impulso para resolver aquilo imediatamente. Mas não há garantia de que, naquele momento, você tenha energia para lidar com isso. A maioria dos sistemas de notificação da web parece uma imitação desajeitada do que clientes de email já tinham resolvido décadas atrás. Talvez os antigos estivessem mesmo certos em usar email

    • Email também é notificação; você pode explicar melhor como exatamente alguém estaria no humor de receber isso no momento em que chega?

  • Muita gente já ficou irritada quando a Microsoft absorveu o GitHub. Só que, na prática, as alternativas muitas vezes eram ruins. O Sourceforge é interminavelmente irritante para abrir issues, o GitLab é melhor que o Sourceforge, mas eu também não gosto de abrir issues lá. O Codeberg parece ter mudado a UI recentemente, mas ainda é bem incômodo
    O que o GitHub fez bem no começo foi a UI e o foco em facilitar as coisas para quem usa GitHub. Mas não acertou tudo; acho o suporte a wiki horrível. É tão ruim que quase não uso wiki. O problema realmente grande, para mim, são os interesses comerciais, ou seja, interesses privados. A Microsoft é só um exemplo; esse problema existe em quase todo site parecido. Já usei como exemplo antes a discussão de issues sobre o utilitário com backdoor do xz, e eu mesmo participei dela, mas no dia seguinte a Microsoft tirou tudo do ar. Não importa se foi a Microsoft ou o dono do repositório. O problema é que um indivíduo pode censurar informação potencialmente útil com facilidade demais. Aquela discussão de issues era útil e foi censurada. Se bem me lembro, nem tudo foi restaurado depois. Talvez alguém tenha espelhado, mas eu não vi links. Isso mostra como o controle de cima para baixo pode ser realmente prejudicial. Sinceramente, até que ponto dá para confiar na Microsoft? Precisamos de algo descentralizado, estável, que funcione bem, com UI padrão boa, e simples ou pelo menos com um bom fluxo de trabalho. Também precisamos evitar uma situação em que um ator privado mantenha todo mundo refém. Não faço ideia de como resolver isso, e talvez precise de várias abordagens ao mesmo tempo. A web mudou, e especialmente os interesses privados das megacorporações pioraram muito as coisas nos últimos 10–15 anos. Isso precisa mudar

    • O problema é que operar um produto SaaS custa caro
      Grandes empresas conseguem bancar isso, mas um monte de desenvolvedores com orçamento pequeno, mesmo juntos, não tem dinheiro para fazer o mesmo. Então qualquer projeto comercial acaba inevitavelmente tendendo a apoiar mais os interesses das grandes empresas do que os da pessoa comum