Por que alguns grandes projetos, como Git e Debian, usam apenas uma lista de discussão e não um rastreador de problemas?

O rastreador de bugs para qualquer projeto de tamanho decente parece um acéfalo para mim - facilita muito a organização de centenas ou milhares de problemas, sem que os problemas colidam ou se misturem.

Então, quando vejo alguns projetos realmente grandes, como o Git, usando uma lista de discussão como o principal método de coordenação de manutenção e desenvolvimento, fico um pouco impressionado. Exemplos:

• Git - Página da comunidade :

  ... Os relatórios de erros devem ser enviados para esta lista de discussão.

• Sistema de rastreamento de bugs da Debian , de acordo com a Wikipedia:

  ... Sua característica única é que ela não possui nenhuma forma de interface da web para editar relatórios de erros - todas as modificações são feitas por email.

Muitos rastreadores de bugs modernos têm uma integração muito boa com o e-mail (você pode receber comentários ou notificações sobre bugs que estiver assistindo ou atribuídos a você), bem como com sistemas de controle de versão (confirmações podem ser marcadas como solução de um problema etc.) .). Muito disso teria que ser feito manualmente com uma lista de e-mails, e você recebe muitos e-mails sobre bugs nos quais não está interessado.

Então, quais são as principais vantagens de uma lista de discussão sobre um rastreador de erros baseado na Web? Por que alguns grandes projetos usam apenas uma lista de endereços?

A preferência que você observa parece uma consequência natural da recomendação claramente declarada nos Padrões de Codificação GNU . Sugere relatar erros por e-mail, como você pode ver na citação abaixo (marquei em negrito a parte que aborda diretamente suas observações):

4.7.2 --help

A --helpopção padrão deve gerar uma breve documentação sobre como chamar o programa, na saída padrão, e sair com sucesso. Outras opções e argumentos devem ser ignorados quando isso for visto, e o programa não deve executar sua função normal.

Perto do final da ‘--help’saída da opção, coloque linhas indicando o endereço de email para relatórios de erros , a página inicial do pacote (normalmente ‘http://www.gnu.org/software/pkg’e a página geral para obter ajuda sobre o uso de programas GNU. O formato deve ser o seguinte:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Não há problema em mencionar outras listas de discussão e páginas da web apropriadas.

A preferência acima, por sua vez, reflete a aceitação universal do email como uma forma de comunicação eletrônica. Qualquer usuário --helpque esteja lendo uma mensagem como sugerido acima deve entender facilmente o que fazer se vir uma mensagem de erro - é fácil.

O rastreador de problemas pode ser (e acho que é ) melhor para um desenvolvedor que trabalha no projeto, mas para um público mais amplo seria mais difícil apresentar e explicar como usá-lo, especialmente levando em consideração a grande variedade e diferenças entre os diferentes sistemas de rastreamento de problemas .

Um projeto pode usar o Bugzilla, outro ficará com o JIRA, o terceiro com ... GNATS , etc etc etc. Não há como apresentar todo esse "zoológico" de uma maneira que seria tão padrão e uniforme quanto possível.

Report bugs to: mailing-address

A observação acima não significa que os projetos não devam usar o rastreador de problemas internamente . Conforme explicado em uma excelente resposta à pergunta relacionada ,

Seu rastreador de erros é para sua conveniência, não para o de seus clientes. Se você não pode se incomodar em pegar o problema por telefone ou e-mail e inseri-lo, como acha que eles se sentem?

Você precisa inserir problemas e atribuí-los manualmente a um cliente ...

Com o Git, em particular, há um motivo histórico simples: o Git foi iniciado por hackers do Linux para hackers do Linux e usa o mesmo modelo e ferramentas de desenvolvimento que o próprio Linux. O Linux, no entanto, é mais antigo que a WWW; portanto, quando o Linux foi iniciado, simplesmente não havia rastreadores de problemas baseados na Web, porque não havia Web!

Como conseqüência, a comunidade Linux desenvolveu ferramentas e fluxos de trabalho extremamente eficientes para lidar com relatórios de erros e revisões de código por e-mail, e não havia razão para eles descartarem todo esse trabalho e começarem do zero quando iniciaram o projeto Git.

Para Git:

Existem várias discussões na lista de discussão em que as pessoas se propõem a usar algum tipo de rastreador de erros. Essas iniciativas parecem ter fracassado; portanto, o motivo pelo qual o Git não usa um rastreador de erros provavelmente é simplesmente porque a maioria dos colaboradores não o considera útil.

Em um post na lista de discussão , Junio ​​C Hamano (mantenedor do Git) resumiu por que ele acha que um rastreador de bugs não é muito útil. Não quero incluir o post inteiro (é bastante longo), mas tudo se resume a:

• Se você está procurando apenas informações sobre problemas resolvidos, pesquisar nos arquivos da lista funciona tão bem quanto pesquisar em um rastreador de erros.
• Se você relatar um bug genuíno e as pessoas quiserem cuidar dele, a lista também funcionará bem.
• Se ninguém estiver interessado em trabalhar em um problema, ele cairá nas falhas, mesmo em um rastreador de erros.
• Um rastreador de bugs seria mais um sistema que precisa ser mantido, verificado regularmente se há novos bugs, corrigido bugs fechados etc., em resumo, trabalho extra para pouco benefício.

O Debian usa um rastreador de erros, sua interface padrão é o email. E é conveniente. Lucas Nussbaum, atual líder do projeto Debian, postou alguns dias atrás :

debbugs é o software por trás do Sistema de Rastreamento de Bugs (BTS) da Debian. Também é usado pelo projeto GNU. Apesar de muitas vezes ser percebido como antigo, ele possui vários recursos exclusivos, como o rastreamento do status dos bugs em cada versão e ramificação de um pacote) ou a capacidade de executar todas as interações por email, facilitando o trabalho. offline ou em ambientes mal conectados.

A última parte é um recurso matador aqui - basta colocar na fila esses relatórios na fila de correio local até você sair do avião!

• Mantém crianças de 9 anos de idade.
• Não há necessidade de criar uma conta separada para cada fórum.
• [menor] Experiência consistente do usuário em diferentes listas de discussão e uma curva de aprendizado zero ao se inscrever em uma nova lista.
• Funciona offline. você pode se conectar à Internet e baixar um lote de e-mails, depois fazer caminhadas, escrever suas respostas enquanto desfruta da mãe natureza e enviá-las mais tarde.
• Permite criptografar e / ou assinar emails via GPG.
• Descentralizado - Se o fórum falhar, você ainda terá uma cópia, também é resistente a violações, um moderador / hacker do mal não pode violar facilmente o que você disse. Ninguém pode desfazer a história.
• Permite filtros, pastas e todos os recursos organizacionais avançados de um cliente de email.
• "Push Notifications" - você pode deixar seu cliente de email aberto e receber notificações de novas respostas.
• Um lugar para governar todos eles - não há necessidade de pular entre sites diferentes.
• Imune a todas as vulnerabilidades de segurança que envolvem a web (html / javascript / injeções etc.)
• Sem inchaço - sem emblemas, assinaturas em movimento, anúncios, web beacons, inchaço de javascript. É tudo simples e direto ao ponto - discussão.
• Menos carga do servidor que uma configuração LAMP.

Uma desvantagem das listas de discussão que vem à mente é que os fóruns são dividíveis em categorias e subcategorias, enquanto as listas de discussão não são. Isso pode ser emulado dividindo-se uma lista de endereçamento em várias listas de endereçamento e, em seguida, os usuários podem usar os filtros apropriados para colocar cada mensagem na pasta correspondente (cada pasta é uma categoria). Nos fóruns da web, isso é automático.