               Escrevendo Relatorios de Problemas para o FreeBSD

  Dag-Erling Smo/rgrav

   Contribuido por  

  Mark Linimon

   Revisao: e79ea0d1f2

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of
   International Business Machines Corporation in the United States, other
   countries, or both.

   Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium,
   Pentium, and Xeon are trademarks or registered trademarks of Intel
   Corporation or its subsidiaries in the United States and other countries.

   Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM,
   Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks
   or registered trademarks of Sun Microsystems, Inc. in the United States
   and other countries.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2019-06-17 22:18:56 +0000 por Danilo G. Baio.
   Resumo

   Este artigo descreve como redigir e submeter um bom relatorio de problemas
   ao Projeto FreeBSD.

   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Introduc,ao

   2. Quando Enviar um Relatorio de Problemas

   3. Preparativos

   4. Escrevendo o Relatorio do Problema

   5. Acompanhamento

   6. Se Existir Problemas

   7. Leitura Adicional

   Indice Remissivo

1. Introduc,ao

   Uma das experiencias mais frustrantes que alguem pode ter como usuario de
   um software e submeter um relatorio de problema apenas para ve-lo ser
   encerrado sumariamente com uma explicac,ao curta e inutil tal como "nao e
   um bug" ou "PR Falso". Da mesma forma, uma das experiencias mais
   frustrantes como desenvolvedor de software e ser inundado com relatorios
   de problemas que nao sao realmente relatorios de problemas mas sim pedidos
   de suporte, ou entao por relatorios que contem pouca ou nenhuma
   informac,ao sobre o que e o problema e sobre como reproduzi-lo.

   Este documento tenta descrever como escrever bons relatorios de problemas.
   O que, alguem pergunta, e um bom relatorio de problemas? Bem, para ir
   diretamente para ao ponto, um bom relatorio de problema e aquele que pode
   ser analisado e tratado rapidamente, para a satisfac,ao mutua do usuario e
   do desenvolvedor.

   Embora o foco principal deste artigo esteja nos relatorios de problemas do
   FreeBSD, a maioria das recomendac,oes deve se aplicar muito bem a outros
   projetos de software.

   Observe que este artigo e organizado por temas, nao de uma forma
   cronologica. Leia todo o documento antes de enviar um relatorio de
   problemas, em vez de trata-lo como um tutorial passo a passo.

2. Quando Enviar um Relatorio de Problemas

   Existem muitos tipos de problemas, e nem todos devem gerar um relatorio de
   problemas. Naturalmente, ninguem e perfeito, e havera momentos em que o
   que parece ser um bug em um programa e, na verdade, um equivoco na sintaxe
   de um comando ou um erro tipografico em um arquivo de configurac,ao
   (embora isto por si so possa ser um indicativo de uma documentac,ao
   deficiente ou de deficiencias no manuseio de erros pelo aplicativo).
   Existem ainda muitos casos em que submeter um relatorio de problema
   claramente nao e o curso de ac,ao correto, e so servira para frustrar
   tanto o usuario e quanto o desenvolvedor. Por outro lado, existem casos em
   que pode ser apropriado enviar um relatorio de problema sobre algo
   diferente de um bug - tal como um aprimoramento ou um novo recurso, por
   exemplo.

   Entao, como se determina o que e um bug e o que nao e? Como uma regra
   simples, o problema nao e um bug se ele puder ser expresso como uma
   pergunta (geralmente na forma "Como fac,o X?" ou "Onde posso encontrar
   Y?"). Nem sempre e tao preto e branco, mas a regra da pergunta cobre a
   grande maioria dos casos. Ao procurar por uma resposta, considere colocar
   a questao na lista de discussao de perguntas gerais sobre o FreeBSD.

   Considere estes fatores ao enviar PRs sobre ports ou outros softwares que
   nao fazem parte do proprio FreeBSD:

     * Por favor, nao envie relatorios de problemas que simplesmente afirmam
       que uma versao mais nova de um aplicativo esta disponivel. Os
       mantenedores de ports sao notificados automaticamente pelo portscout
       quando uma nova versao de um aplicativo fica disponivel. Patches para
       atualizar um port para uma versao mais recente do software sao sempre
       bem-vindos.

     * Para ports nao mantidos (O seu MAINTAINER e ports@FreeBSD.org), e
       improvavel que um PR que nao tenha um patch incluido seja escolhido
       para ser trabalhado por um committer. Para se tornar o mantenedor de
       um port nao mantido, envie um PR com o pedido (sera otimo se o pedido
       vier com um patch, mas isso nao e obrigatorio).

     * Em ambos os casos, seguir o processo descrito no Porter's Handbook
       produzira os melhores resultados. (Voce tambem pode desejar ler a
       sec,ao Contribuindo para a Colec,ao de Ports do FreeBSD.)

   Um bug que nao pode ser reproduzido raramente pode ser corrigido. Se o bug
   ocorreu apenas uma vez e voce nao pode reproduzi-lo, e nao parece
   acontecer com mais ninguem, e muito provavel que nenhum dos
   desenvolvedores consiga reproduzi-lo ou descobrir o que esta errado. Isso
   nao significa que isso nao tenha acontecido, mas significa que as chances
   do seu relatorio de problema levar `a correc,ao do bug sao muito pequenas.
   Para piorar, muitas vezes esses tipos de bugs sao causados
   &#8203;&#8203;por discos rigidos com defeito ou por processadores
   superaquecidos - sempre que possivel voce deve tentar descartar essas
   causas antes de enviar um PR.

   Em seguida, para decidir para quem voce deve enviar seu relatorio de
   problema, voce precisa entender que o software que compoe o FreeBSD e
   composto por varios elementos diferentes:

     * Codigo no sistema base que e escrito e mantido por contribuidores do
       FreeBSD, como o kernel, a biblioteca C e os drivers de dispositivo
       (categorizados como kern); os utilitarios binarios (bin); as paginas
       de manual e documentac,ao (docs); e as paginas web (www). Todos os
       erros nestas areas devem ser reportados aos desenvolvedores do
       FreeBSD.

     * Codigo no sistema base que e escrito e mantido por outras pessoas, o
       qual e importado e adaptado para o FreeBSD. Exemplos incluem o
       clang(1) e o sendmail(8). A maioria dos bugs nessas areas deve ser
       reportada aos desenvolvedores do FreeBSD; mas em alguns casos eles
       podem precisar ser relatados aos autores originais se os problemas nao
       forem especificos do FreeBSD.

     * Aplicativos individuais que nao estao no sistema base, mas que sao
       parte da colec,ao de ports do FreeBSD (categoria ports). A maioria
       desses aplicativos nao sao escritos por desenvolvedores do FreeBSD; o
       que o FreeBSD fornece e meramente um framework para instalar o
       aplicativo. Portanto, apenas relate um problema para os
       desenvolvedores do FreeBSD quando o problema for considerado
       especifico do FreeBSD; caso contrario, informe aos autores do
       software.

   Em seguida, verifique se o problema e oportuno. Ha poucas coisas que
   incomodarao mais um desenvolvedor do que receber um relatorio de problemas
   sobre um bug que ele ja corrigiu.

   Se o problema estiver no sistema base, primeiro leia a sec,ao Versoes do
   FreeBSD do FAQ, se voce ainda nao estiver familiarizado com o topico. Nao
   e possivel para o FreeBSD consertar problemas em nada alem de certas
   branchs recentes do sistema base, de forma que enviar um relatorio de bug
   sobre uma versao mais antiga provavelmente resultara em um desenvolvedor
   aconselhando voce a atualizar para uma versao suportada para ver se o
   problema ainda continua ocorrendo. A equipe do Security Officer mantem a
   lista das versoes suportadas .

   Se o problema estiver em um port, considere submeter o bug para o
   upstream. O Projeto FreeBSD nao pode corrigir todos os erros em todos os
   softwares.

3. Preparativos

   Uma boa regra a seguir e sempre fazer uma pesquisa sobre o tema antes de
   enviar um relatorio de problemas. Talvez o problema ja tenha sido relatado
   anteriormente; talvez esteja sendo discutido nas listas de discussao, ou
   foi discutido recentemente; pode ate mesmo ja estar corrigido em uma
   versao mais recente da que voce esta executando. Portanto, voce deve
   verificar todos os lugares obvios antes de enviar seu relatorio de
   problemas. Para o FreeBSD, isso significa:

     * A lista das Perguntas Mais Frequ:entes (FAQ) sobre o FreeBSD. A FAQ
       tenta fornecer respostas para uma ampla variedade de perguntas, como
       aquelas relacionadas `a compatibilidade de hardware , aplicativos de
       usuario e configurac,ao do kernel.

     * As listas de discussao - se voce nao esta inscrito, fac,a uma pesquisa
       nos arquivos historicos&#8203;&#8203; das listas no site do FreeBSD.
       Se o problema nao tiver sido discutido nas listas, voce pode tentar
       postar uma mensagem sobre ele e aguardar alguns dias para ver se
       alguem consegue detectar algo que foi esquecido.

     * Opcionalmente, na web toda - use seu mecanismo de pesquisa favorito
       para localizar qualquer referencia ao problema. Voce pode ate receber
       hits de listas de discussao arquivadas ou grupos de noticias que voce
       nao conhecia ou que nao pensou em pesquisar.

     * Em seguida, fac,a uma pesquisa no banco de dados de Relatorios de
       Problemas do FreeBSD (Bugzilla). A menos que o problema seja recente
       ou obscuro, ha uma boa chance de que ele ja tenha sido relatado.

     * Mais importante ainda, tente verificar se a documentac,ao existente
       nao enderec,a o seu problema.

       Para o codigo fonte do FreeBSD, voce deve estudar cuidadosamente o
       conteudo do /usr/src/UPDATING em seu sistema ou a ultima versao
       disponivel em https://svnweb.freebsd.org/base/head/UPDATING?view=log.
       (Esta e uma informac,ao vital se voce estiver atualizando de uma
       versao para outra - especialmente se voce estiver atualizando para a
       Branch FreeBSD-CURRENT).

       No entanto, se o problema estiver em algo que foi instalado como parte
       da colec,ao de ports do FreeBSD, voce deve consultar
       /usr/ports/UPDATING (para ports individuais) ou /usr/ports/CHANGES
       (para alterac,oes que afetam toda a colec,ao de ports). O
       https://svnweb.freebsd.org/ports/head/UPDATING?view=log e o
       https://svnweb.freebsd.org/ports/head/CHANGES?view=log tambem estao
       disponiveis via svnweb.

4. Escrevendo o Relatorio do Problema

   Agora que voce decidiu que seu problema merece um relatorio de problema e
   que ele e um problema especifico do FreeBSD, e hora de escrever o
   relatorio de problema. Antes de entrarmos na mecanica do sistema utilizado
   para gerar e enviar os PRs, aqui estao algumas dicas e truques para ajudar
   a garantir que seu o PR seja mais eficaz.

  4.1. Dicas e Truques para Escrever um Bom Relatorio de Problemas

     * Nao deixe a linha "Summary" vazia. Os PRs sao enviados para listas de
       discussao no mundo todo (onde o "Summary" e usado para a linha de
       Subject:), alem de serem armazenadas em um banco de dados. Qualquer
       pessoa que vier a navegar no banco de dados pelas sinopses, e
       encontrar um PR com a linha de assunto em branco, tende a pula-lo.
       Lembre-se que os PRs permanecem na base de dados ate que sejam
       fechados por alguem; os anonimos normalmente irao desaparecer em meio
       ao ruido.

     * Evite usar um "Summary" (Sumario) fraco. Voce nao deve presumir que
       alguem que esteja lendo seu PR conhec,a o contexto que motivou o seu
       envio, desta forma, quanto mais informac,ao voce fornecer, melhor. Por
       exemplo, em qual parte do sistema o problema se aplica? O problema
       ocorre durante a instalac,ao ou durante a execuc,ao do sistema? Para
       ilustrar, em vez de usar Summary: o portupgrade esta quebrado, veja o
       quanto mais informativo isso parece: Summary: port
       ports-mgmt/portupgrade gerando coredumps no -current. (No caso de um
       port, e especialmente util ter tanto o nome da categoria quanto o nome
       do port na linha "Summary".)

     * Se voce tem um patch, mencione-o. Um PR com um patch incluido e muito
       mais provavel de ser analisado do que um sem. Por favor, inclua a
       palavra-chave patch no Bugzilla.

     * Se voce e um mantenedor, informe. Se voce esta mantendo uma parte do
       codigo fonte (por exemplo, um port existente), voce deve definir o
       campo "Class" do seu PR para maintainer-update. Desta forma, qualquer
       committer que lide com seu PR nao tera que verificar.

     * Seja especifico. Quanto mais informac,oes voce fornecer sobre o
       problema que esta tendo, maiores serao suas chances de obter uma
       resposta.

          * Inclua a versao do FreeBSD que voce esta utilizando (ha um lugar
            para colocar essa informac,ao, veja abaixo) e em qual
            arquitetura. Voce deve incluir se voce esta executando a partir
            de uma release (por exemplo, de um CD-ROM ou feito um download),
            ou de um sistema mantido pelo Subversion (e, caso seja
            afirmativo, em qual numero de revisao voce esta). Se voce estiver
            utilizando a branch FreeBSD-CURRENT, essa e a primeira coisa que
            alguem vai perguntar, porque as correc,oes (especialmente para
            problemas de alto nivel) tendem a ser realizadas muito
            rapidamente, e e esperado que usuarios do FreeBSD-CURRENT se
            mantenham atualizados.

          * Inclua quais opc,oes globais voce especificou em seu make.conf,
            src.conf e src-env.conf. Dado o numero infinito de opc,oes, nem
            todas as combinac,oes podem ser totalmente suportadas.

          * Se o problema puder ser reproduzido facilmente, inclua
            informac,oes que irao ajudar um desenvolvedor a reproduzi-lo. Se
            um problema puder ser demonstrado com uma entrada especifica,
            entao inclua um exemplo desta entrada se possivel, e inclua tanto
            a saida real quanto a esperada. Se esses dados forem grandes ou
            nao puderem ser tornados publicos, entao tente criar um arquivo
            pequeno que exiba o mesmo problema e que possa ser incluido no
            PR.

          * Se este for um problema do kernel, esteja preparado para fornecer
            as seguintes informac,oes. (Voce nao precisa inclui-las por
            padrao, o que apenas tende a preencher o banco de dados, mas voce
            deve incluir os trechos que considera ser relevantes):

               * sua configurac,ao do kernel (incluindo quais dispositivos de
                 hardware voce tem instalado)

               * independente de voce ter ou nao opc,oes de debug habilitadas
                 (como WITNESS), e se tiver, se o problema persiste quando
                 voce muda o sentido da opc,ao

               * o texto completo de qualquer backtrace, panic ou outra
                 mensagens de console, ou registros em /var/log/messages, se
                 houver sido gerado

               * a saida de pciconf -l e partes relevantes da saida do
                 comando dmesg se o seu problema estiver relacionado a uma
                 pec,a especifica de hardware

               * o fato de voce ter lido src/UPDATING e o seu problema nao
                 estar listado la (alguem pode perguntar)

               * independente de voce poder executar qualquer outro kernel
                 como um fallback (isso e para descartar problemas
                 relacionados a hardware, como discos com falhas e CPUs
                 superaquecidas, que podem se passar por problemas de kernel)

          * Se este for um problema de algum port, esteja preparado para
            fornecer as seguintes informac,oes. (Voce nao precisa inclui-las
            por padrao, o que apenas tende a preencher o banco de dados, mas
            voce deve incluir trechos que voce considera relevantes):

               * quais ports voce instalou

               * quaisquer variaveis &#8203;&#8203;de ambiente que
                 sobreescrevem as variaveis padroes em bsd.port.mk, assim
                 como PORTSDIR

               * o fato de voce ter lido ports/UPDATING e o seu problema nao
                 estar listado la (e garantido que alguem ira perguntar)

     * Evite requisic,oes vagas de novas funcionalidades. Os PRs no formato
       "alguem realmente deve implementar algo que faz isso e aquilo" tem
       menor probabilidade de obter resultados do que requisic,oes muito
       especificas. Lembre-se, o codigo fonte esta disponivel para todos,
       entao se voce quiser uma nova funcionalidade, a melhor maneira de
       garantir que ela seja incluida e comec,ar a trabalhar! Considere
       tambem o fato de que muitas coisas como essa seriam um topico melhor
       para a discussao sobre freebsd-questions do que uma entrada no banco
       de dados de PR, como discutido acima.

     * Certifique-se de que ninguem mais tenha submetido um PR similar.
       Embora isso ja tenha sido mencionado acima, vale a pena repetir aqui.
       Leva apenas um ou dois minutos para usar o mecanismo de busca baseado
       na Web em https://bugs.freebsd.org/bugzilla/query.cgi. (Claro, todo
       mundo e culpado de esquecer de fazer isso de vez em quando.)

     * Relate um problema apenas atraves do Relatorio de Problemas. Evite
       incluir dois ou mais problemas dentro do mesmo relatorio, a menos que
       estejam relacionados. Ao enviar patches, evite adicionar varias
       funcionalidades ou corrigir multiplos bugs no mesmo PR, a menos que
       eles estejam intimamente relacionados - esses PRs geralmente levam
       mais tempo para serem resolvidos.

     * Evite requisic,oes controversas. Se o seu PR aborda uma area que ja
       foi controversa no passado, voce provavelmente devera estar preparado
       para nao apenas oferecer patches, mas tambem justificar por que os
       patches sao "A Coisa Certa A Se Fazer ". Como observado acima, uma
       busca cuidadosa nas listas de discussao usando os arquivos em
       https://www.FreeBSD.org /search/search.html#mailinglists e sempre uma
       boa preparac,ao.

     * Seja educado. Quase todo mundo que potencialmente ira trabalhar em seu
       PR e um voluntario. Ninguem gosta que digam o que eles tem que fazer
       quando ja estao fazendo por alguma motivac,ao que nao seja o ganho
       monetario. E sempre bom ter isso em mente em projetos de codigo
       aberto.

  4.2. Antes de Comec,ar

   Considerac,oes semelhantes se aplicam ao uso do formulario de envio de PR
   web-based (com base em web). Cuidado com as operac,oes de recortar e colar
   que podem alterar o espac,os em branco ou outras formatac,oes de texto.

   Finalmente, se o envio for demorado, prepare o trabalho off-line para que
   nada seja perdido se houver um problema ao envia-lo.

  4.3. Anexando Patches ou Arquivos

   Ao anexar um patch, certifique-se de usar svn diff ou diff(1) com o
   argumento -u para criar ou unificar o diff e certificar-se de especificar
   os numeros de revisao exatos do SVN dos arquivos que voce modificou para
   que os desenvolvedores que lerem seu relatorio possam aplica-los
   facilmente. Para problemas com o kernel ou com os utilitarios de base, um
   patch para o FreeBSD-CURRENT (a branch HEAD do Subversion) e o preferido,
   ja que todo codigo novo deve ser aplicado e testado la primeiro. Apos
   testes apropriados ou substanciais terem sido feitos, o codigo sera
   mesclado/migrado para a branch FreeBSD-STABLE.

   Se voce anexar um patch inline, em vez de um anexo, observe que o problema
   mais comum, de longe, e a tendencia de alguns programas de email
   renderizar tabs como espac,os, o que ira arruinar completamente qualquer
   coisa destinada a fazer parte de um Makefile.

   Nao envie correc,oes como anexos usando Content-Transfer-Encoding:
   quoted-printable. Isso ira escapar os caracteres e todo o patch se tornara
   inutil.

   Observe tambem que, embora a inclusao de pequenos patches em um PR
   geralmente esteja correto - particularmente quando eles corrigem o
   problema descrito no PR - patches grandes e especialmente codigos novos
   que podem exigir uma revisao substancial antes do commit, deveriam ser
   colocados em um servidor web ou FTP, e a URL deveria ser incluida no PR em
   vez do patch. Patches por e-mail tendem a ficar embaralhados, e quanto
   maior o patch, mais dificil sera para as partes interessadas recupera-lo.
   Alem disso, postar um patch na web permite modifica-lo sem ter que
   reenviar todo o patch em um followup do PR original. Finalmente, os
   patches grandes simplesmente aumentam o tamanho do banco de dados, uma vez
   que os PRs fechados nao sao realmente excluidos, mas sim mantidos e
   simplesmente marcados como completos.

   Voce tambem deve observar que, a menos que voce especifique explicitamente
   o contrario em seu PR ou no proprio patch, quaisquer patches enviados por
   voce serao considerados licenciados sob os mesmos termos do arquivo
   original que voce modificou.

  4.4. Preenchendo o formulario

  Nota:

   O enderec,o de e-mail que voce usa se tornara publico e podera se tornar
   disponivel para spammers. Voce deve ter procedimentos de tratamento de
   spam ou usar uma conta de email temporaria. No entanto, observe que, se
   voce nao usar uma conta de e-mail valida, nao poderemos fazer perguntas
   sobre seu PR.

   Quando voce for reportar um bug, voce encontrara os seguintes campos:

     * Summary (Sumario): Preencha com uma descric,ao breve e precisa do
       problema. A sinopse e usada como assunto do email do relatorio de
       problemas. A sinopse e usada em listagens e resumos de relatorios de
       problemas; relatorios de problemas com sinopses obscuras tendem a ser
       ignoradas.

     * Severity (Gravidade): Um dos Affects only me (Afeta somente eu),
       Affects some people (Afeta algumas pessoas) ou Affects many people
       (Afeta muitas pessoas). Nao exagere; abstenha-se de rotular seu
       problema como Afeta muitas pessoas a menos que ele realmente afete. Os
       desenvolvedores do FreeBSD nao irao necessariamente trabalhar no seu
       problema mais rapido se voce inflar sua importancia, uma vez que
       existem muitas outras pessoas que fizeram exatamente isso.

     * Category (Categoria): Escolha uma categoria apropriada.

       A primeira coisa que voce precisa fazer e decidir em que parte do
       sistema esta seu problema. Lembre-se, o FreeBSD e um sistema
       operacional completo, que instala tanto um kernel, bibliotecas padrao,
       muitos drivers de perifericos e um grande numero de utilitarios (o
       "sistema basico"). No entanto, existem milhares de aplicativos
       adicionais na colec,ao de portes. Voce primeiro precisa decidir se o
       problema esta no sistema basico ou algo instalado via a Colec,ao de
       Ports.

       Aqui esta uma descric,ao das categorias principais:

          * Se um problema for com o kernel, as bibliotecas (como a
            biblioteca C padrao libc), ou o driver de algum periferico no
            sistema base, em geral voce ira usar a categoria kern. (Existem
            algumas excec,oes; veja abaixo). Em geral, sao coisas descritas
            nas sec,oes 2, 3 ou 4 das paginas de manual.

          * Se o problema for com um programa binario, como sh(1) ou
            mount(8), primeiro voce precisara determinar se esses programas
            estao no sistema basico ou se foram adicionados por meio da
            Colec,ao de Ports. Se nao tiver certeza, voce pode executar
            whereis nome_do_programa. A convenc,ao do FreeBSD para a Colec,ao
            de Ports e instalar tudo abaixo do /usr/local, embora esse
            comportamento possa ser alterado por um administrador do sistema.
            Para estes, voce usara a categoria ports (sim, mesmo se a
            categoria do port for www; veja abaixo). Se a localizac,ao for
            /bin, /usr/bin, /sbin , ou /usr/sbin, ele faz parte do sistema
            base, e voce deve usar a categoria bin. Essas sao todas as coisas
            descritas na sec,ao 1 ou 8 das paginas de manual.

          * Se voce acredita que o erro esta nos scripts de inicializac,ao
            (rc), ou em algum outro tipo de arquivo de configurac,ao
            nao-executavel, entao a categoria correta e conf (configurac,ao)
            . Estas sao as coisas descritas na sec,ao 5 das paginas de
            manual.

          * Se voce encontrou um problema no conjunto de documentac,ao
            (artigos, livros, man pages) ou no website, a escolha correta e
            docs.

  Nota:

            Se voce estiver tendo um problema com algum port chamado
            www/algum nome de port, mesmo assim, isso vai na categoria ports.

       Existem algumas categorias mais especializadas.

          * Se o problema, por outro lado, estar colocado em kern, mas tem a
            ver com o subsistema USB, a escolha correta e usb.

          * Se o problema, por outro lado, estiver colocado em kern, mas tem
            a ver com as bibliotecas de threads, a escolha correta e threads.

          * Se o problema, por outro lado, estiver no sistema base, mas tem a
            ver com nossa fidelidade a padroes como POSIX(R), a escolha
            correta e standards.

          * Se estiver convencido de que o problema ocorrera apenas sob a
            arquitetura do processador que voce esta usando, selecione uma
            das categorias especificas da arquitetura: geralmente i386 para
            maquinas compativeis com Intel 32 bits; amd64 para maquinas AMD
            rodando em 64 bits (isto tambem inclui maquinas compativeis com
            Intel rodando em modo EMT64); e menos comumente, as arquiteturas
            arm ou powerpc.

  Nota:

            Estas categorias sao muitas vezes mal utilizadas para problemas
            definidos como "Eu nao sei". Em vez de adivinhar, por favor
            apenas use a categoria misc.

            Exemplo 1. Uso Correto da Categoria Especifica de Arquitetura

            Voce tem uma maquina comum baseada em PC e acha que encontrou um
            problema especifico para um determinado chipset ou uma placa-mae
            em particular: i386 e a categoria correta.

            Exemplo 2. Uso Incorreto da Categoria Especifica de Arquitetura

            Voce esta tendo um problema com uma placa periferica adicional em
            um barramento comum, ou um problema com um tipo especifico de
            unidade de disco rigido: neste caso, provavelmente se aplica a
            mais de uma arquitetura, e kern e a categoria correta.

          * Se voce realmente nao sabe onde o problema se encaixa (ou a
            explicac,ao nao parece se encaixar nos itens acima), use a
            categoria misc. Antes de fazer isso, voce pode pedir ajuda
            primeiro na lista de discussao de perguntas gerais do FreeBSD.
            Voce pode ser avisado que com certeza uma das categorias
            existentes e uma escolha melhor.

     * Environment: Isto deve descrever, com a maior precisao possivel, o
       ambiente em que o problema foi observado. Isto inclui a versao do
       sistema operacional, a versao do programa ou arquivo especifico que
       contem o problema e quaisquer outros itens relevantes, como
       configurac,ao do sistema, outro software instalado que influencia no
       problema, etc. - simplesmente tudo o que um desenvolvedor precisa
       saber para reconstruir o ambiente em que ocorra o problema.

     * Description: Uma descric,ao completa e precisa do problema que voce
       esta enfrentando. Tente evitar especular sobre as causas do problema,
       a menos que tenha certeza de que voce esta no caminho certo, pois isso
       pode induzir o desenvolvedor a fazer suposic,oes incorretas sobre o
       problema. Ela deve incluir as ac,oes que voce precisa executar para
       reproduzir o problema. Se voce conhece alguma soluc,ao alternativa,
       inclua-a. Ela nao apenas ajuda outras pessoas com o mesmo problema a
       contorna-lo, mas tambem pode ajudar um desenvolvedor a entender a
       causa do problema.

5. Acompanhamento

   Uma vez que o relatorio de problema foi colocado na fila, voce recebera
   uma confirmac,ao por e-mail que incluira o numero de rastreamento que foi
   atribuido ao seu relatorio de problema e uma URL que voce pode usar para
   verificar seu status. Com um pouco de sorte, alguem se interessara por seu
   problema e tentara resolve-lo, ou, conforme o caso, explicar por que isso
   nao e um problema. Voce sera automaticamente notificado de qualquer
   alterac,ao de status e recebera copias de quaisquer comentarios ou
   correc,oes que alguem possa anexar `a trilha de auditoria do seu relatorio
   de problemas.

   Se alguem solicitar informac,oes adicionais de voce, lembrar ou descobrir
   algo que voce nao mencionou no relatorio inicial, por favor, adicione um
   novo comentario de acompanhamento. O motivo numero um para um bug nao ser
   corrigido e a falta de comunicac,ao com o criador do relatorio. A maneira
   mais facil de fazer isso e usar a opc,ao de comentario na pagina da Web
   individual do PR, que voce pode acessar a partir da pagina de pesquisa de
   PRs.

   Se o relatorio de problemas permanecer aberto apos o desaparecimento do
   problema, basta adicionar um comentario dizendo que o relatorio de
   problemas pode ser fechado e, se possivel, explicar como ou quando o
   problema foi corrigido.

   As vezes, ha um atraso de uma semana ou duas em que o relatorio do
   problema permanece intocado, nao atribuido ou comentado por alguem. Isto
   pode acontecer quando ha um aumento na lista de pendencias de relatorios
   de problemas ou durante uma temporada de feriados. Quando um relatorio de
   problema nao recebe atenc,ao apos varias semanas, vale a pena encontrar um
   committer particularmente interessado em trabalhar nele.

   Existem algumas maneiras de se fazer isso, idealmente na seguinte ordem,
   com alguns dias entre a tentativa em cada canal de comunicac,ao:

     * Encontre a lista de discussao relevante do FreeBSD para o relatorio de
       problemas listadas no Handbook e envie uma mensagem para essa lista
       perguntando sobre assistencia ou comentarios sobre o relatorio do
       problema.

     * Junte-se aos canais relevantes do IRC. Uma lista parcial esta aqui:
       https://wiki.freebsd.org/IrcChannels. Informe as pessoas nesse canal
       sobre o relatorio de problemas e pec,a ajuda. Seja paciente e fique no
       canal depois de postar, para que as pessoas de diferentes fusos
       horarios ao redor do mundo tenham a chance de responder.

     * Encontre committers interessados &#8203;&#8203;no problema que foi
       relatado. Se o problema estiver em uma ferramenta, binario, porta,
       documento ou arquivo fonte especifico, verifique o Repositorio SVN.
       Localize os ultimos committers que fizeram alterac,oes substanciais no
       arquivo e tente falar com eles pelo IRC ou por email. Uma lista de
       committers e seus e-mails podem ser encontrados no artigo Contributors
       do FreeBSD.

   Lembre-se de que essas pessoas sao voluntarias, assim como mantenedores e
   usuarios, portanto, podem nao estar disponiveis imediatamente para ajudar
   no relatorio de problemas. Paciencia e consistencia nos acompanhamentos
   sao altamente recomendados e apreciados. Com cuidado e esforc,o
   suficientemente dedicados a esse processo de acompanhamento, encontrar um
   committer para cuidar do relatorio do problema e apenas uma questao de
   tempo.

6. Se Existir Problemas

   Se voce encontrou um problema com o sistema de bugs, registre um bug!
   Existe uma categoria exatamente para esse proposito. Se voce nao
   conseguir, entre em contato com os organizadores do bug em
   <bugmeister@FreeBSD.org>.

7. Leitura Adicional

   Esta e uma lista de recursos relevantes para a escrita adequada e
   processamento de relatorios de problemas. Nao esta de modo algum completo.

     * Como reportar bugs efetivamente -um excelente ensaio de Simon G.
       Tatham sobre como compor de forma util relatorios de problemas (nao
       especificos do FreeBSD).

     * Orientac,oes para o tratamento dos relatorios de problemas
       -informac,oes valiosas sobre como os relatorios de problemas sao
       tratados pelos desenvolvedores do FreeBSD.

Indice Remissivo

  R

   relatorios de problemas, Escrevendo Relatorios de Problemas para o FreeBSD
