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

63

O rastreador de bugs para qualquer projeto de tamanho decente parece um pouco óbvio para mim - facilita organizar centenas ou milhares de problemas, sem problemas ou misturas.

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:

Muitos rastreadores de bugs modernos têm uma integração muito boa com e-mail (você pode receber comentários ou notificações sobre bugs que está assistindo ou que são atribuídos a você), bem como para sistemas de controle de versão (os commits podem ser marcados como resolvendo questão, etc.). Muito disso teria que ser feito manualmente com uma lista de e-mails e você receberia 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 bugs baseado na web? Por que alguns grandes projetos usam apenas uma lista de discussão?

    
por naught101 26.03.2013 / 07:18
fonte

5 respostas

46

A preferência que você observa parece uma conseqüência natural da recomendação claramente indicada em Padrões de codificação GNU . Ele sugere para relatar bugs por e-mail, como você pode ver na citação abaixo (marquei negrito a parte que aborda diretamente suas observações):

4.7.2 --help

The standard --help option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘--help’ option’s output, please place lines giving the email address for bug reports, the package’s home page (normally ‘http://www.gnu.org/software/pkg’, and the general page for help using GNU programs. The format should be like this:

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

It is ok to mention other appropriate mailing lists and web pages.

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 lendo a mensagem --help , como sugerido acima, deve entender facilmente o que fazer se vir um bug - o envio de e-mails é fácil.

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

Um projeto pode usar o Bugzilla, outro vai ficar com o JIRA, terceiro com ... GNATS , etc etc, etc. Simplesmente não há como apresentar todo esse" zoológico "de uma forma que seria tão padrão e uniforme quanto

Report bugs to: mailing-address

Observação acima não significa que os projetos não devam usar o rastreador de problemas internamente . Conforme explicado em um excelente resposta à questão relacionada ,

Your bug tracker is for your convenience, not your customers'. If you can't be bothered to take their phone or email issue and enter it yourself, how do you think they feel?

You need to be able to enter issues and assign them manually to a client...

    
por 26.03.2013 / 10:04
fonte
28

Com o Git, em particular, há uma razão histórica simples: o Git foi iniciado por hackers do Linux para hackers do Linux e usa o mesmo modelo de desenvolvimento e ferramentas que o próprio Linux. O Linux, no entanto, é mais antigo que o WWW, então, quando o Linux foi iniciado, simplesmente não eram 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 bugs e revisões de código por e-mail, e não havia razão para eles jogarem todo esse trabalho fora e começar do zero quando eles iniciaram o trabalho. Projeto Git.

    
por 26.03.2013 / 11:43
fonte
15

Para o Git:

Existem várias discussões na lista de discussão onde as pessoas propõem usar algum tipo de rastreador de bugs. Todas essas iniciativas parecem ter fracassado, então o motivo pelo qual o Git não usa um rastreador de bugs é provavelmente que a maioria dos contribuidores não o considera útil.

Em uma postagem na lista de discussão , Junio C Hamano (mantenedor do Git) resumiu porque ele acha que um bug tracker não é muito útil. Eu não quero incluir o post inteiro (é bem longo), mas tudo se resume a:

  • Se você está procurando apenas informações sobre problemas resolvidos, pesquisar os arquivos da lista funciona tão bem quanto pesquisar um rastreador de bugs.
  • 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 vai cair nas rachaduras, mesmo em um bug tracker.
  • Um rastreador de bugs seria mais um sistema que precisa ser mantido, checado por novos bugs regularmente, bugs corrigidos fechados etc., em suma, trabalho extra para pouco benefício.
por 26.03.2013 / 18:02
fonte
6

O Debian usa um bug tracker, sua interface padrão é email. E isso é conveniente. Lucas Nussbaum, atual Líder do Projeto Debian, postado há alguns dias :

debbugs is the piece of software behind the Debian Bugs Tracking System (BTS). It is also used by the GNU project. Despite often being perceived as old-style, it features several unique features, such as the tracking of the status of bugs in each version and branch of a package ), or the ability to perform all interactions via email, making it very easy to work offline or in poorly-connected environments.

A última parte é um recurso matador aqui - apenas enfileire esses relatórios em sua fila de correio local até você sair do avião!

    
por 16.10.2013 / 13:34
fonte
4
  • Mantém 9 anos de idade.
  • Não é necessário criar uma conta separada para cada fórum.
  • [menor] Experiência consistente do usuário em diferentes listas de e-mail e uma curva de aprendizado zero ao se inscrever em uma nova lista.
  • Funciona off-line. você pode se conectar à Internet e baixar um lote de e-mails, então faça caminhadas, escreva suas respostas enquanto desfruta da mãe natureza e enviá-los mais tarde.
  • Permite a criptografia de e-mail e / ou assinatura via GPG.
  • Descentralizado - Se o fórum travar, você ainda tem uma cópia, é também inviolável, um moderador / hacker malvado não pode facilmente adulterar com 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 obter notificações de novas respostas.
  • Um lugar para governar todos eles: não é necessário alternar 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 extravagantes, anúncios, web beacons, bloat 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 divididos em categorias e subcategorias, enquanto as listas de discussão não são. Isso pode ser emulado dividindo uma lista de discussão em várias listas de discussão e, em seguida, os usuários podem usar os filtros apropriados para colocar cada mensagem com sua pasta correspondente (cada pasta sendo uma categoria). Em fóruns da web, isso é automático.

    
por 17.09.2014 / 07:56
fonte