2. Quando enviar um relatório de problema

Existem muitos tipos de problemas, e nem todos eles devem gerar um relatório de problema. É claro, ninguém é perfeito e em algumas ocasiões você terá certeza de que encontrou um bug em um determinado software quando na verdade você compreendeu errado a sintaxe de um comando ou mesmo cometeu um erro de digitação em um arquivo de configuração (o que por sua vez pode indicar uma documentação pouco detalhada ou então um tratamento inadequado do erro por parte da aplicação). Existem ainda muitas outras situações nas quais enviar um relatório de problema claramente não é a melhor ação a ser tomada, e só vai servir para frustrar a você e aos desenvolvedores. Em contrapartida, existem situações nas quais é recomendado que você nos envie um relatório de problema sobre outras coisas que não um bug, como por exemplo para nos enviar uma sugestão de melhoria ou um pedido de uma nova funcionalidade.

Então como você irá diferenciar o que é e o que não é um bug? Existe uma regra de ouro que diz que o seu problema não é um bug se ele pode ser expresso como uma pergunta (normalmente na forma “Como eu faço X” ou “Onde eu posso encontrar Y”). Na maior parte das vezes não será sempre tão claro desta forma, mas a regra acima cobre a grande maioria dos casos. Se você estiver procurando por uma resposta, considere enviar a sua pergunta para lista de discussão para perguntas gerais sobre o FreeBSD.

Veja alguns casos nos quais pode ser apropriado enviar um relatório de problema sobre algo que não é um bug:

• Pedidos de melhorias nas funcionalidades. Geralmente é uma boa idéia debater estas propostas nas listas de discussão antes de enviá-las em um relatório de problemas.

• Notificações sobre atualizações de softwares mantidos externamente (principalmente do ports, mas também de componentes do sistema base como, por exemplo, o BIND e vários outros utilitários GNU).

  Para os ports sem manutenção (aqueles nos quais a variável MAINTAINER contém [email protected]), essas notificações de atualização podem ser capturadas por um committer interessado, ou você pode ser solicitado a fornecer um patch para atualizar o port; disponibilizar este patch antecipadamente irá melhorar de forma significativa as suas chances de ter o port atualizado rapidamente.

  Se o port possui um mantenedor, o envio de um relatório de problema comunicando sobre o lançamento de uma nova versão geralmente não é muito útil uma vez que eles geram trabalho adicional para os committers, e o mantenedor provavelmente já tem conhecimento de que existe uma nova versão, ele provavelmente já trabalhou com os desenvolvedores para atualizá-lo e está provavelmente executando testes para verificar se não existem problemas, etc.

  Em ambos os casos, você irá obter melhores resultados se seguir o processo descrito no Porter's Handbook. (Talvez você também queira ler o artigo Contribuindo para a Coleção de Ports do FreeBSD.)

Um bug que não pode ser reproduzido, raramente será corrigido. Se o bug ocorreu uma única vez e você não consegue reproduzi-lo, e se aparentemente ele não ocorre com mais ninguém, as chances são de que nenhum dos desenvolvedores será capaz de reproduzir ou de saber o que está errado. Isso não significa que não seja possível, mas significa que a probabilidade do seu relatório de problema resultar na correção do bug é muito pequena. Para piorar a situação, muitas vezes este tipo de erro é, na realidade, causado por falhas nos discos rígidos ou por superaquecimento do processador — sempre que possível você deve tentar excluir estas causas antes de enviar um relatório de problema.

Em seguida, para decidir a quem você deve apresentar o seu relatório de problema, você precisa entender que o FreeBSD é composto de vários elementos de software diferentes:

• Código na base do sistema que é escrito e mantido por colaboradores do FreeBSD, tais como o Kernel, a biblioteca C, os drivers de dispositivos (categorizados como kern); os utilitários binários (bin); as páginas de manual e a documentação (docs); e as páginas web (www). Todos os bugs nestas áreas devem ser reportados para os desenvolvedores do FreeBSD

• Código na base do sistema que é escrito e mantido por outros, e que foram adaptados e importados no FreeBSD. Exemplos incluen bind, gcc(1), e sendmail(8). A maioria dos bugs nestas áreas devem ser reportados para os desenvolvedores do FreeBSD; mas em alguns casos pode ser necessário reportá-los aos autores originais, caso o problema não seja especifico do FreeBSD. Normalmente estes bugs irão ficar sob as categorias bin ou gnu.

• Os aplicativos individuais que não estão na base do sistema, mas que fazem parte da coleção de Ports do FreeBSD (Categoria ports). A maioria destes aplicativos não são escritos por desenvolvedores do FreeBSD; o que o FreeBSD oferece é apenas um sistema para facilitar a instalação do aplicativo. Portanto, você deve relatar um problema para os desenvolvedores do FreeBSD apenas quando você acreditar que o problema é específico do FreeBSD, caso contrário, você deve reportá-lo aos autores do software.

A seguir você deve verificar se o problema é ou não atual. Existem poucas coisas que aborrecem um desenvolvedor mais do que receber um relatório de problema a respeito de um bug que ele já corrigiu.

Se o problema está na base do sistema, você deverá primeiro ler a seção do FAQ sobre Versões do FreeBSD, se você não estiver familiarizado com o tema. Não é possível para o FreeBSD corrigir problemas em versões muito antigas do sistema base, desta forma enviar um relatório de problema sobre um bug em uma versão muito antiga vai provavelmente resultar apenas em um desenvolvedor aconselhando que você atualize o seu sistema para uma versão suportada para ver se o problema ainda ocorre. A equipe de Security Officer mantém a lista de versões suportadas.

Se o problema está em um port, observe que você deverá primeiro atualizar seu sistema para a versão mais atual da coleção de ports e ver se o problema ainda se aplica. Devido ao ritmo acelerado de mudanças nestas aplicações, é inviável para o FreeBSD suportar qualquer coisa que não seja obrigatoriamente a versão mais recente, e problemas com uma versão antiga do aplicativo simplesmente não podem ser corrigidos.