Existem revisões de código em projetos de código-fonte aberto? Se sim, quais ferramentas são usadas para fazer isso?

Eu sei que há um grande impulso para revisões de código no desenvolvimento comercial. No entanto, as revisões de código são usadas no software de código aberto ou são baseadas na confiança? Se sim, então como eles são realizados? [É um commit atrasado, "um ambiente de pré-commit", existe uma ferramenta que permite que o patch seja enviado para outro desenvolvedor?

Existem projetos que usam revisões de código?

Pelo meu entendimento, o kernel do Linux é principalmente baseado na confiança do committer. O MySQL foi baseado na aprovação do autor principal e no impacto no desempenho.

Quase todos os projetos de código-fonte aberto usam algum tipo de fluxo de trabalho de gatekeeper, em que uma pessoa ou grupo de pessoas deve assinar todas as alterações para entrar na compilação oficial. Alguns projetos maiores, como o kernel do Linux, têm camadas de gatekeepers. Você envia uma alteração para alguém que gerencia uma área de um subsistema, eles enviam suas alterações para alguém que gerencia um subsistema inteiro e enviam suas alterações para Linus Torvalds, que às vezes revisa o código por conta própria ou às vezes confia nos seus tenentes. Essas revisões geralmente não têm uma estrutura formal. É apenas alguém olhando o código antes que ele seja mesclado.

Quanto às ferramentas, observe o mecanismo de solicitação de recebimento no github para obter um bom exemplo. Você faz uma solicitação pull e, em uma página da web dedicada a essa solicitação, as pessoas fazem comentários e o autor faz revisões até que seja bom o suficiente para aceitar. Outros gatekeepers usam o git simples para aplicar patches de listas de discussão ou mesclar solicitações pull de repositórios públicos, que é uma das principais razões pelas quais DVCSes como o git foram inventados.

Os projetos de código aberto geralmente têm (e devem, se não tiverem) um conjunto claramente publicado de "diretrizes da comunidade", que geralmente inclui uma descrição do fluxo de trabalho do projeto e como as contribuições são aceitas (e, portanto, como são testadas). como o processo para se tornar um colaborador principal.

No que diz respeito à revisão de código, novamente depende da comunidade, mas as diretrizes são frequentemente esclarecidas. Alguns exemplos de diretrizes para contribuições de não-confirmadores variam de "vitórias de código de trabalho" a "contribuições devem ter cobertura e documentação de teste completas, com testes executados ao mesmo tempo que o código" e tudo mais; independentemente dessas diretrizes, a única diretriz implícita é que os comprometedores principais revisarão toda e qualquer contribuição de não comprometedores antes de aceitá-los.

Projetos de código aberto com grupos de comprometedores principais também costumam ter reuniões virtuais ou tempo dedicado para discutir qualquer contribuição que possa precisar de olhares extras - bem como o processo SE de vários votos próximos de usuários de uma certa reputação antes que uma pergunta seja encerrada, e a discussão de coisas questionáveis ​​via meta ou chat.

Aqui estão alguns links rápidos para alguns exemplos de documentos da comunidade para projetos que eu conheço melhor, onde você pode encontrar respostas para sua pergunta específica para esses projetos (em breve você verá um tema):

• Princípios da comunidade do Project Blacklight
• Diretrizes de contribuição de código do DSpace
• Guia técnico de colaboradores do Apache

Projetos maiores de OSS terão vários comprometedores principais. Então eu acho que eles são os "revisores de código" de fato.

Além disso, como o código OSS é por natureza aberto a todos, é provável que haja muito mais discussão sobre o código que você está escrevendo. Embora isso possa não estar na forma de revisões formais de código, você certamente descobrirá se seu código não é considerado adequado para um projeto OSS específico.