não use o mantis, use o trac

16 de março de 2007

Hoje acordei com a macaca e resolvi falar mal do Mantis, gratuitamente.

Alguns meses atrás uma empresa para qual prestei serviços trocou o gerenciador de projetos Trac pelo bug tracker Mantis e, como eu fui radicalmente contra, agora resolvi falar porque eu acho que trocar o Trac pelo Mantis é uma cagada sem precedentes na história da humanidade.

Primeiro

Substituir um ambiente Trac já configurado e funcional para um com Mantis é de uma irresponsabilidade tremenda. O Trac é um set de ferramentas para gerenciamento do desenvolvimento de algo e ultrapassa todas as características do Mantis (que se resumem a gerenciador tickets de suporte e requests). Ou seja, você destrói recursos de trabalho em favor de...

Motivações

Opinões pessoais inócuas. Isso fode. Muito. Mais do que deveria.

Isso me faz lembrar da importância de um gerenciador de projetos. É extramamente complicado você lidar com vários técnicos programando, mexendo em infra-estrutura e fazendo testes e documentações, homologando código etc etc sem ter algumas coisas mínimas (na minha opinião):

  • Controle de versão
  • Wiki ou área de documentação
  • Gerenciador de bugs (tracker)

Pois o Trac tem tudo isso de forma integrada. No caso do controle de versão, ele possui um dos melhores browsers pro Subversion que eu já vi: simples, direto e eficiente na comparação de revisões pra culpar commits de desatentos. Do wiki e do bug tracker dele eu falo mais abaixo, mas quando você ignora as features de algo bom como o Trac (e usado por certo tempo em algum lugar - ou seja, plenamente funcional) e simplesmente fica falando coisas como "o Mantis é melhor e pronto", "Porque sim" ou ainda "Mantis é animal, vamos usar!" as coisas saem do controle...

Migração

Nessa parte eu deveria falar sobre como migrar de um para o outro no caso de você não ter muita saída, mas vou me limitar a dizer que o Trac aceita normalmente os tickets abertos no Mantis e os importa no seu bug tracker interno. O Mantis não; o contrário não é possível... ha!

Inclusive é até bem engraçado ver o pessoal que insiste no Mantis e instala programas "add-ons" para suprir necessidades que ele não atende. E esse é o caso do Wiki.

Se alguém que precisa de um Wiki bom, rápido, bem configurável, estável e feito para documentação e desenvolvimento me perguntasse qual eu recomendo eu diria o DokuWiki. Tenho usado eles por anos (sei lá, acho que por uns 2) em coisas minhas e garanto como é bom. Tão bom que os próprios desenvolvedores do Mantis o usam no site!

Ou seja, você joga fora o wiki interno do Trac (que assumidamente não chega aos pés do Doku, mesmo isso não sendo problema algum) e instala o Doku em paralelo com o Mantis. Dois programas pra fazer o trabalho de um.

Quer dizer, três no lugar de um. Porque o Mantis não possui integração alguma com controladores de versões; esqueça Subversion. Se quiser ter um browser SVN junto com seu bug tracker vai ter que instalar um WebSVN ou ViewVC da vida... separadamente, claro.

Extras

Outra coisa relacionada que o Mantis não suporta e o Trac sim (através de um plug-in entre tantos outros do Trac-Hacks, se não me engano) é a integração entre tickets de desenvolvimento fechados ou ativos com revisões específicas do repositório de código. Ou seja, você não precisa ficar que nem o pessoal sem noção do Asterisk.org (que é um dos poucos projetos grandes que vi usando Mantis) que ao fechar um ticket adiciona uma anotação extra com o número da revisão do Subversion. Quem já teve problemas com documentação de sistemas sabe que isso é um baita adiantamento de trabalho.

Além disso, o Trac permite você visualizar o status de fechamentos de tickets até alcançar um determinado milestone pré-definido, dando a chance de você saber a quantas anda o trabalho e como está o nível da próxima versão dos seus softwares ou produtos. Também permite que você crie formulários especiais para os tickets, não se limitando ao padrão ou no máximo novos campos "extras".

Uma coisa a se pensar na migração são os modelos de relatórios dos bug trackers deles. O Mantis até permite salvar modelos, mas baseando-se nos formulários existentes. Já o Trac te permite criar relatórios de qualquer tipo, arbitrariamente. Você monta SQLs do SQLite "ao vivo" e já vê o resultado na interface. Gostou? Salva.

Não seria complicado também fazer alguns scripts que até convertessem a sintaxe do DokuWiki (pro caso daqueles que o usam com o Mantis) para ficar no padrão do wiki interno do Trac.

Produtividade

Aqui o Mantis até ganha bons pontos. Um recurso legal dele que eu não vi no Trac ainda é uma listagem de estatísticas do desenvolvimento, que permite você ver quem fechou mais bugs, entre quais datas e bugs de quais e tais níveis. Novamente, no caso do Asterisk.org isso é perceptivelmente interessante, dado o grande volume de trabalho e desenvolvedores com karma.

Em compensação, o Mantis não tem um suporte tão decente a feeds (XML, RSS, Atom, CSV... seja lá o que você usa pra criar notificações). Que eu saiba até existem opções disso nele, mas não se compara as formas variadas de notificações que o Trac oferece. Cheguei até mesmo a fazer um plug-in chamado TracNoty que pega notificações de bugs abertos por desenvolvedor e pipoca no desktop KDE dele os chamados para serem fechados, até serem fechados mesmo.

É claro que isso é extremamente chato e burocrático de fazer no Mantis, por esse tipo de coisa não estar tão óbvia na interface ou não ser tão bem trabalhada. E não, não cheguei a ter tempo de usar o plug-in... e por que não? Porque migraram pro Mantis uma semana depois que o terminei heheh.

Conclusão

Se algum dia alguém virar pra você e tentar enfiar o Mantis garganta abaixo, lembre-se disso tudo que tá acima. Ambientes de desenvolvimento precisam de recursos integrados (unificados) o quanto for possível. Dar manutenção em tanta coisa solta, e infelizmente inferior, só atrasa a vida.

UPDATE: eu não testo a versão do Mantis nem do Trac vinda do trunk deles (prefiro usar versões comprovadamente estáveis e garantidas), então talvez alguns comentários acima estejam inválidos em relação a estas versões (a conferir)

© caio1982