O que você gostaria de ver em um forge?

• Usuários do Jujutsu e de outros sistemas de controle de versão, assim como fluxos de trabalho puros de Git que os principais forges não cobrem bem, estão em discussão
• O principal interesse não está na forma de implementação, como SPA/JS ou HTML renderizado no servidor, mas em como o repositório representa e faz funcionar os recursos de controle de versão
• Há ideias como Tangled, stacked PRs do GitHub e forgefed, mas é difícil encontrar um espaço onde as opiniões dos usuários sobre o design se reúnam
• Isso também inclui stacked PR/MR e modelos alternativos de colaboração, e a principal questão é a experiência de controle de versão para além dos forges existentes
• A exibição de objetos do repositório como tags, commits, árvores e blobs é em geral parecida entre os forges, e quase não há discussão além de pequenas diferenças de formatação

[GN⁺]

Opiniões no Lobste.rs

• Comentários de revisão de código que não façam parte do próprio repositório são algo que eu jamais usaria
  Armazenar contexto histórico valioso em listas de e-mail, silos de banco de dados ou em uma camada separada que não fica fixada ao hash do commit HEAD é, no fundo, o mesmo tipo de risco do GitHub
  O Fossil vai um pouco nessa direção, mas lida só com issues e a revisão de código ainda é no estilo patch por e-mail: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Quando essa informação entra no sistema de controle de versão, aí dá para colocar por cima uma interface web legal, feed RSS e lista de e-mail
  A segunda funcionalidade é suporte nativo a merge queue. Em projetos minimamente relevantes, contribuidores individuais não deveriam fazer push direto para a branch main; ao marcar um commit específico como “pronto para integrar”, um bot deveria serializar as mudanças propostas, agendar o CI da melhor forma e avançar a main para hashes validados
  A terceira funcionalidade é CI como executor isolado de tarefas em ambientes heterogêneos, como Windows e macOS: https://gregoryszorc.com/blog/2021/…

  • Além disso, é preciso uma abordagem clara para lidar com spam e abuso
    Qualquer pessoa deveria poder criar uma conta e abrir uma issue, mas sem spam
    Hoje o GitHub faz isso bastante bem. Às vezes vejo spam, mas ele é removido muito rápido depois de ser denunciado como abuso. Imagino que por trás haja uma mistura de automação e uma equipe real de triagem
  • Existe hoje alguma ferramenta que guarde comentários de revisão de código dentro do repositório?
    Estou olhando o Fossil como “forge” para projetos pessoais, e não acho que vá ter muitos contribuidores externos, então revisão de código seria mais um extra útil
  • Eu não gostaria de colocar issues e pull requests dentro do repositório em si
    Em vez disso, quero um banco SQLite que eu possa sincronizar, enviar e consultar como quiser
    A próxima grande refatoração que quero fazer no git-pr é expor o banco SQLite como um comando SSH: ssh pr.pico.sh sql
    SQLite está em todo lugar e é genérico o bastante para o que precisamos, mas falta a usabilidade de tratá-lo como parte da forge
  • Colocar comentários de revisão de código no próprio repositório é uma ideia realmente interessante
    Só fico me perguntando, em casos de reescrita de histórico como force-push ou squash merge, a que exatamente esses comentários ficariam “presos” depois, para o usuário conseguir encontrá-los
    No GitHub, a referência é o Pull Request, então dá para ver a discussão mesmo se os commits incluídos mudarem
    Fico curioso se esse sistema também teria um conceito separado de PR armazenado no repositório, ou se a expectativa é algo mais fortemente integrado
  • Não sei muito bem como isso se combinaria com hashes de commit, nem como encarar o problema de os metadados do repositório oscilarem tanto
    Ainda assim, como uso jj com bastante satisfação, talvez na prática isso nem seja um problema tão grande

• Depois de usar tanto Gerrit quanto e-mail, acho uma pena que o modelo de pull request seja tão dominante
  Isso vale especialmente quando um mantenedor poderia simplesmente corrigir detalhes menores de estilo em vez de deixar comentário, e o contribuidor provavelmente nem se importa tanto com esse tipo de ajuste
  Mas o que me incomoda ainda mais é que não exista nenhum fluxo de trabalho não baseado em e-mail para Darcs ou Pijul, que venho usando cada vez mais
  Em vez de e-mail, eu gostaria de algo baseado em XMPP. Daria para fazer colaboração distribuída em tempo real sobre patches em andamento, até com um MUC por patchset
  O MUC pode ser aberto como um chat de voz e já tem funções como papéis, anexos, reações, busca, MAM, moderação e tombstoning após a conclusão, tudo já definido em XEPs
  Daria para usar PubSub para assinaturas e também como meio de transporte para CI
  Para ser realmente prático, precisaria de um cliente dedicado, mas muitas funções já poderiam simplesmente funcionar em qualquer cliente
  Talvez, realisticamente, isso seja mais um reflexo do meu fascínio recente por ver tecnologia federada antiga se expandindo de maneiras inesperadas

• Revisão e aprovação de código são o gargalo
  A comunicação com quem enviou o código tem latência muito alta, às vezes leva semanas ou meses, e a confiabilidade também é baixa. Tem gente que abre um PR e some
  O modelo do GitHub, que presume interação de ida e volta, simplesmente desmorona aqui
  Seria ótimo poder corrigir o código diretamente durante a revisão e fazer amend dos commits, como no git-absorb. Ficar indo e voltando com o autor por causa de coisas pequenas como typos é perda de tempo, e o hack de Edit Suggestion do GitHub é trabalhoso e bagunça o histórico
  Eu não quero revisar o mesmo código de novo. Se o problema estiver só em uma função ou em um commit, o resto deveria poder ser pré-aprovado, e quando o autor corrigisse com force-push eu não deveria precisar rever tudo
  Seria ótimo poder fazer merge só de parte de um PR, ou remover commits sem fechar o PR. Às vezes você não quer a funcionalidade em si, mas vale a pena preservar o trabalho de base para ela; em outros casos entram “limpezas” ou formatações desnecessárias
  Quando o autor original não responde, outras pessoas deveriam poder colaborar no PR, lapidar e resolver os problemas. No modelo do GitHub isso até é possível em teoria, mas na prática parece mais um truque escondido de fazer PR em cima de outro PR, e esse código e essas notificações nem ficam visíveis para o projeto de destino. Quando as pessoas fazem fork e abrem PRs de correção, isso só gera confusão e conflitos de merge
  Muitas vezes o código enviado está razoavelmente bom, mas eu queria pequenos ajustes. Do ponto de vista do autor, é frustrante sentir que o PR está sendo mantido refém até que todo acabamento esteja perfeito; do ponto de vista do mantenedor, se fizer merge logo de cara há o risco de o autor desaparecer e as melhorias seguintes nunca acontecerem. Seria bom haver um jeito de fazer um merge provisório com a obrigação de limpar depois. Por exemplo, fazer merge em uma staging branch, mas não fazer cherry-pick para a branch estável até que os FIXME sejam resolvidos
  Em projetos populares de código aberto, às vezes existe só 1 pessoa capaz de fazer revisão e aprovação que realmente mova o projeto para frente, enquanto há 500 pessoas querendo contribuir e ajudar umas às outras. O modelo do GitHub não aproveita em nada essa capacidade excedente de contribuição. Em vez de ajudar a colaboração, transforma isso em crise, confusão e pressão coletiva irritada. Deveria haver suporte muito melhor a gerenciamento de forks e cópia de código entre forks, para que outras pessoas possam experimentar e avançar o projeto sem ficar bloqueadas por um único mantenedor, e para que o mantenedor consiga escolher facilmente mudanças populares e comprovadamente funcionais entre vários forks

  • Se quem abriu o PR não ativou a configuração que bloqueia isso, o dono do repositório pode fazer push direto na branch do PR
    Acho que em organizações isso era o padrão, mas de qualquer forma nesse caso dá para limpar tudo direto com force-push
    Sempre faço isso para correções pequenas que não valem a ida e volta
  • Se você acha que o autor do PR demora, experimente esperar uma resposta de mantenedor
    Normalmente isso parece ser medido em meses ou anos
    Às vezes eu também sou o mantenedor, e reconheço que eu mesmo nem sempre sou mais rápido que isso
  • Mesmo que a interface web de revisão não consiga editar o código diretamente, seria bom se ela ficasse muito mais próxima de uma IDE
    Quero coisas como ir para definição e pop-ups ao passar o mouse mostrando assinatura ou comentário de documentação
    Dá para ter isso fazendo checkout da branch e revisando no editor de sua preferência, mas como eu disse, revisão é o gargalo
    O trabalho extra de ficar trocando de branch toda vez que vou revisar vários PRs é grande demais

• Precisa haver modo usuário único, ou pelo menos um modo de usuário único
  Por que eu deveria aceitar URLs como https://code.chrismorgan.example/chrismorgan/repository-name? https://code.chrismorgan.example/repository-name já deveria bastar
  Estou falando sério, e https://github.com/go-gitea/gitea/issues/11028 mostra que claramente muita gente quer isso
  Uma das três principais razões de eu não ter conta no Fediverse é que os endereços são horríveis
  Se eu usar @‌me@‌chrismorgan.info como endereço principal de e-mail, para algumas pessoas isso talvez apareça como simplesmente “@‌me”, enquanto @‌chrismorgan@‌chrismorgan.info é desagradável só de olhar
  Nisso o ATProto acertou em cheio. Nomes de domínio funcionam muito bem como handle, e se você precisar de vários usuários, subdomínios já bastam
  Até em uma forge compartilhada, usar subdomínios parece um jeito lógico de fazê-la parecer de usuário único. Pode ser interessante imaginar chris-morgan.github.com em vez de github.com/chris-morgan
  Estética importa
  Ir para usuário único também traz consequências maiores. Se você reduzir algo como Mastodon para uso individual, ele continua pesado; mas projetos do Fediverse desenhados desde o começo para um único usuário se encaixam muito melhor nesse caso
  Quero operar meu próprio servidor, mas com apenas eu como usuário local, e não quero compromissos por causa da possibilidade de existirem outros usuários
  Isso também significa que, nas forges, eu quero fazer push como usuário chris no estilo SSH normal, e não com um usuário genérico como git
  Se estamos falando de forge no sentido mais comum, federação obviamente é necessária. Mas seria bom que cada “servidor doméstico” tivesse só um usuário local

  • Como você usa endereço de e-mail?
    Se usa um domínio com seu próprio nome, não existe lá um problema parecido também?

• Gostei do artigo do Nesbitt sobre esse tema
  Principalmente da parte sobre melhor comunicação com downstreams

• Tem que ser possível fazer revisão de código local no editor escolhido
  Não quero ficar preso a uma interface web limitada com fonte imutável e syntax highlighting horrível
  Hoje uso um fluxo com ferramentas personalizadas para Neovim para visualizar diffs lado a lado de forma agradável, e o comando git pr para fazer checkout de pull requests
  Mas, se eu quiser um pouco mais, como deixar comentários de revisão, já acabo dependente de alguma CLI de terceiros ou ferramenta que fala com a API do GitHub e que provavelmente não estará mantida daqui a 5 anos
  Mais precisamente, não basta só ter ferramentas que “dá para executar” localmente; precisamos de ferramentas local-first que se integrem localmente com o editor e afins
  A dificuldade de isso virar recurso de primeira classe é o esforço necessário. Uma única interface web “funciona” em todas as plataformas e ambientes de edição porque força todo mundo a usá-la, mas integrações mais profundas exigem N integrações se existem N editores e ambientes
  O mesmo vale para CI. Eu quero conseguir rodar testes facilmente em Linux, FreeBSD e macOS, sem fazer push do commit para uma branch e esperar 15 minutos até ele ser processado
  Algo como run-remotely some-command --on freebsd,linux,mac já serviria
  Basicamente, seria um sistema de CI descentralizado e local-first, mas que também dê suporte a um sistema central como fonte única da verdade para garantir que todo código passe pelo mesmo sistema “aprovado” antes do merge
  Isso vai além de um simples ssh user@host command ..., porque envolve copiar o código-fonte, cache, instalar dependências necessárias etc., de modo a obter sempre o mesmo estado confiável

  • Tenho pensado em algo parecido ultimamente
    Mas não vejo isso como funcionalidade de forge. Deveria vir como uma ferramenta de executor de tarefas que você pode usar sem depender de uma forge específica e que qualquer forge possa chamar
    Acho que teria que ser meio “baseada em drivers”. Você poderia executar a mesma tarefa totalmente localmente ou despachá-la para um sistema remoto. Essa tarefa poderia rodar em máquina virtual, contêiner ou diretamente no host

• Também deveria haver suporte a sistemas de controle de versão que não sejam Git
  Deve ser possível importar e exportar issues, wiki etc. em formatos convenientes para não ficar preso a um sistema específico
  Também deveria ser fácil fazer self-hosting

  • Dar suporte a todos os sistemas de controle de versão que não sejam Git é uma lista bem grande
    Provavelmente existe um subconjunto realmente importante
    O Heptapod no comentário irmão é para Mercurial, e sourcehut, também
    O Fossil tem sua própria forge, e o allura, a versão Apache do SourceForge, oferece Subversion

• Seria bom se existisse uma forge que oferecesse algo ao estilo do Bazel na camada de CI
  Não no sentido de “você pode rodar Bazel no CI”, mas como algo que incentive naturalmente as pessoas a escrever boas suítes de teste e build com dependências, para não desperdiçar tempo de CI sem necessidade
  Relacionado a isso, acho que o modelo “um projeto = um repositório” criou muitos problemas
  Você até pode chamar isso de melhor suporte a monorepos, mas no fundo CI e issues, por exemplo, deveriam poder ter escopo maior do que “o topo deste diretório”
  Muita gente divide repositórios por causa da forge ou do CI, e trabalhar assim não é nada divertido
  Como revisor, eu também gostaria de divisão inline de patches
  Quero dizer: deixar eu selecionar as partes que considero boas e aprovar só elas, para integrar o que já está satisfatório
  Acho que PRs empilhados ainda são um conceito pesado demais
  Se alguém diz “quero mudar 4 arquivos e vejo isso como um único PR”, o revisor deveria poder dizer “beleza, estes 2 arquivos estão bons” e transformar esse conjunto de mudanças em uma parte separada do PR, ou até fazer merge só desse pedaço como um commit separado
  Mesmo os PRs empilhados atuais ainda tratam o PR como unidade atômica. Na maioria dos sistemas, o PR parece pesado demais

  • Só uma observação: a JetBrains foi contra por muito tempo permitir commits por hunk
    O motivo era “isso é um subconjunto do arquivo, então não dá para saber se compila”
    Eu não concordo nem um pouco com essa posição, mas ver este comentário me lembrou disso, porque fazer esse tipo de coisa numa interface web exigiria bastante cuidado
    Claro, deixando de lado por um momento a observação do comentário acima de que, se você é o dono do repositório, sempre pode fazer force-push na branch com a versão que preferir

• É preciso ter configuração de CI/CD sem esforço
  Basta make build, make test, make upload
  Se o resto puder ficar no makefile, daí já dá para evoluir para um sistema de build melhor
  Quero ir da ideia ao artefato publicado em menos de 2 minutos

  • Por que usar Make, ainda por cima em várias versões, em vez de usar o que a maioria dos sistemas de CI/CD faz e adotar um arquivo de configuração em um local bem conhecido?
    Bastaria ter três shell scripts com nomes bem conhecidos em um diretório bem conhecido
    Como bônus, se você precisar de build no Windows, eles podem ser arquivos .bat
  • Gosto da abordagem, mas provavelmente também seria preciso uma forma de instalar dependências
    Isso pode variar conforme o sistema operacional, e talvez você não queira colocar isso dentro do makefile
  • Estou construindo um CI local-first que traz isolamento por conta própria: https://ci.pico.sh
    A vantagem é que todos os jobs rodam em seu próprio pty dentro de zmx
    Você pode se conectar a um job que falhou e simplesmente apertar seta para cima e Enter para rodá-lo de novo

• Quero advisories de segurança com trilhos de proteção para que dados de qualidade sejam publicados
  Precisamos de um ecossistema centrado em commits para que todo projeto consiga publicar dados significativos, e os projetos que quiserem também deveriam ter integração para emitir CVEs diretamente