path: root/pt_BR.ISO8859-1/articles/problem-reports/article.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:lang="pt_BR">

  <info>
    <title>Escrevendo Relatórios de Problemas para o FreeBSD</title>

    <legalnotice xml:id="trademarks" role="trademarks">
      <para>FreeBSD is a registered trademark of the FreeBSD Foundation.</para>
      <para>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.</para>
      <para>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.</para>
      <para>SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. SPARC International, Inc owns all of the SPARC trademarks and under licensing agreements allows the proper use of these trademarks by its members.</para>
      <para>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.</para>
      <para>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 <quote>™</quote> or the <quote>®</quote> symbol.</para>
    </legalnotice>

    <pubdate xml:lang="en">$FreeBSD$</pubdate>

    <releaseinfo xml:lang="en">$FreeBSD$</releaseinfo>

    <abstract>
      <para>Este artigo descreve como redigir e submeter um bom relatório de problemas ao Projeto FreeBSD.</para>
    </abstract>

    <authorgroup>
      <author><personname> <firstname>Dag-Erling</firstname> <surname>Smørgrav</surname> </personname> <contrib> Contribuído por </contrib></author>

      <author><personname> <firstname> Mark</firstname> <surname>Linimon</surname> </personname></author>
    </authorgroup>
  </info>

  <indexterm><primary>relatórios de problemas</primary></indexterm>

  <section xml:id="pr-intro">
    <title>Introdução</title>

    <para>Uma das experiências mais frustrantes que alguém pode ter como usuário de um software é submeter um relatório de problema apenas para vê-lo ser encerrado sumariamente com uma explicação curta e inútil tal como <quote>não é um bug</quote> ou <quote>PR Falso</quote>. Da mesma forma, uma das experiências mais frustrantes como desenvolvedor de software é ser inundado com relatórios de problemas que não são realmente relatórios de problemas mas sim pedidos de suporte, ou então por relatórios que contêm pouca ou nenhuma informação sobre o que é o problema e sobre como reproduzi-lo.</para>

    <para>Este documento tenta descrever como escrever bons relatórios de problemas. O que, alguém pergunta, é um bom relatório de problemas? Bem, para ir diretamente para ao ponto, um bom relatório de problema é aquele que pode ser analisado e tratado rapidamente, para a satisfação mútua do usuário e do desenvolvedor.</para>

    <para>Embora o foco principal deste artigo esteja nos relatórios de problemas do FreeBSD, a maioria das recomendações deve se aplicar muito bem a outros projetos de software.</para>

    <para>Observe que este artigo é organizado por temas, não de uma forma cronológica. Leia todo o documento antes de enviar um relatório de problemas, em vez de tratá-lo como um tutorial passo a passo.</para>
  </section>

  <section xml:id="pr-when">
    <title>Quando Enviar um Relatório de Problemas</title>

    <para>Existem muitos tipos de problemas, e nem todos devem gerar um relatório de problemas. Naturalmente, ninguém é perfeito, e haverá momentos em que o que parece ser um bug em um programa é, na verdade, um equívoco na sintaxe de um comando ou um erro tipográfico em um arquivo de configuração (embora isto por si só possa ser um indicativo de uma documentação deficiente ou de deficiências no manuseio de erros pelo aplicativo). Existem ainda muitos casos em que submeter um relatório de problema claramente <emphasis>não</emphasis> é o curso de ação correto, e só servirá para frustrar tanto o usuário e quanto o desenvolvedor. Por outro lado, existem casos em que pode ser apropriado enviar um relatório de problema sobre algo diferente de um bug - tal como um aprimoramento ou um novo recurso, por exemplo.</para>

    <para>Então, como se determina o que é um bug e o que não é? Como uma regra simples, o problema <emphasis>não</emphasis> é um bug se ele puder ser expresso como uma pergunta (geralmente na forma <quote>Como faço X?</quote> ou <quote>Onde posso encontrar Y?</quote>). Nem sempre é tão preto e branco, mas a regra da pergunta cobre a grande maioria dos casos. Ao procurar por uma resposta, considere colocar a questão na <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions">lista de discussão de perguntas gerais sobre o FreeBSD</link>.</para>

    <para>Considere estes fatores ao enviar PRs sobre ports ou outros softwares que não fazem parte do próprio FreeBSD:</para>

    <itemizedlist>
      <listitem>
	<para>Por favor, não envie relatórios de problemas que simplesmente afirmam que uma versão mais nova de um aplicativo está disponível. Os mantenedores de ports são notificados automaticamente pelo <application>portscout</application> quando uma nova versão de um aplicativo fica disponível. Patches para atualizar um port para uma versão mais recente do software são sempre bem-vindos.</para>
      </listitem>

      <listitem>
	<para>Para ports não mantidos (O seu <varname>MAINTAINER</varname> é <literal>ports@FreeBSD.org</literal>), é improvável que um PR que não tenha um patch incluído seja escolhido para ser trabalhado por um committer. Para se tornar o mantenedor de um port não mantido, envie um PR com o pedido (será ótimo se o pedido vier com um patch, mas isso não é obrigatório).</para>
      </listitem>

      <listitem>
	<para>Em ambos os casos, seguir o processo descrito no <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html">Porter's Handbook</link> produzirá os melhores resultados. (Você também pode desejar ler a seção <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contribuindo para a Coleção de Ports do FreeBSD</link>.)</para>
      </listitem>
    </itemizedlist>

    <para>Um bug que não pode ser reproduzido raramente pode ser corrigido. Se o bug ocorreu apenas uma vez e você não pode reproduzi-lo, e não parece acontecer com mais ninguém, é muito provável que nenhum dos desenvolvedores consiga reproduzi-lo ou descobrir o que está errado. Isso não significa que isso não tenha acontecido, mas significa que as chances do seu relatório de problema levar à correção do bug são muito pequenas. Para piorar, muitas vezes esses tipos de bugs são causados por discos rígidos com defeito ou por processadores superaquecidos - sempre que possível você deve tentar descartar essas causas antes de enviar um PR.</para>

    <para>Em seguida, para decidir para quem você deve enviar seu relatório de problema, você precisa entender que o software que compõe o FreeBSD é composto por vários elementos diferentes:</para>

    <itemizedlist>
      <listitem>
	<para>Código no sistema base que é escrito e mantido por contribuidores do FreeBSD, como o kernel, a biblioteca C e os drivers de dispositivo (categorizados como <literal>kern</literal>); os utilitários binários (<literal>bin</literal>); as páginas de manual e documentação (<literal>docs</literal>); e as páginas web (<literal>www</literal>). Todos os erros nestas áreas devem ser reportados aos desenvolvedores do FreeBSD.</para>
      </listitem>

      <listitem>
	<para>Código no sistema base que é escrito e mantido por outras pessoas, o qual é importado e adaptado para o FreeBSD. Exemplos incluem o <citerefentry><refentrytitle>clang</refentrytitle><manvolnum>1</manvolnum></citerefentry> e o <citerefentry><refentrytitle>sendmail</refentrytitle><manvolnum>8</manvolnum></citerefentry>. A maioria dos bugs nessas áreas deve ser reportada aos desenvolvedores do FreeBSD; mas em alguns casos eles podem precisar ser relatados aos autores originais se os problemas não forem específicos do FreeBSD.</para>
      </listitem>

      <listitem>
	<para>Aplicativos individuais que não estão no sistema base, mas que são parte da coleção de ports do FreeBSD (categoria <literal>ports</literal>). A maioria desses aplicativos não são escritos por desenvolvedores do FreeBSD; o que o FreeBSD fornece é meramente um framework para instalar o aplicativo. Portanto, apenas relate um problema para os desenvolvedores do FreeBSD quando o problema for considerado específico do FreeBSD; caso contrário, informe aos autores do software.</para>
      </listitem>
    </itemizedlist>

    <para>Em seguida, verifique se o problema é oportuno. Há poucas coisas que incomodarão mais um desenvolvedor do que receber um relatório de problemas sobre um bug que ele já corrigiu.</para>

    <para>Se o problema estiver no sistema base, primeiro leia a seção <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/introduction.html#LATEST-VERSION"> Versões do FreeBSD</link> do FAQ, se você ainda não estiver familiarizado com o tópico. Não é possível para o FreeBSD consertar problemas em nada além de certas branchs recentes do sistema base, de forma que enviar um relatório de bug sobre uma versão mais antiga provavelmente resultará em um desenvolvedor aconselhando você a atualizar para uma versão suportada para ver se o problema ainda continua ocorrendo. A equipe do Security Officer mantém a <link xlink:href="@@URL_RELPREFIX@@/security/">lista das versões suportadas </link>.</para>

    <para>Se o problema estiver em um port, observe que você deverá primeiro atualizar para a versão mais recente da Coleção de Ports e verificar se o problema ainda se aplica. Devido ao ritmo acelerado de mudanças nesses aplicativos, é inviável que o FreeBSD ofereça suporte para qualquer coisa que não seja absolutamente a versão mais recente e os problemas com versões mais antigas de aplicativos simplesmente não podem ser corrigidos.</para>
  </section>

  <section xml:id="pr-prep">
    <title>Preparativos</title>

    <para>Uma boa regra a seguir é sempre fazer uma pesquisa sobre o tema antes de enviar um relatório de problemas. Talvez o problema já tenha sido relatado anteriormente; talvez esteja sendo discutido nas listas de discussão, ou foi discutido recentemente; pode até mesmo já estar corrigido em uma versão mais recente da que você está executando. Portanto, você deve verificar todos os lugares óbvios antes de enviar seu relatório de problemas. Para o FreeBSD, isso significa:</para>

    <itemizedlist>
      <listitem>
	<para>A lista das <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/index.html">Perguntas Mais Freqüentes</link> (FAQ) sobre o FreeBSD. A FAQ tenta fornecer respostas para uma ampla variedade de perguntas, como aquelas relacionadas à <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/hardware.html">compatibilidade de hardware </link>, <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/applications.html"> aplicativos de usuário</link> e <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/kernelconfig.html"> configuração do kernel</link>.</para>
      </listitem>

      <listitem>
	<para>As <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">listas de discussão</link> - se você não está inscrito, faça uma pesquisa nos arquivos <link xlink:href="https://www.FreeBSD.org/search/search.html#mailinglists">históricos das listas</link> no site do FreeBSD. Se o problema não tiver sido discutido nas listas, você pode tentar postar uma mensagem sobre ele e aguardar alguns dias para ver se alguém consegue detectar algo que foi esquecido.</para>
      </listitem>

      <listitem>
	<para>Opcionalmente, na web toda - use seu mecanismo de pesquisa favorito para localizar qualquer referência ao problema. Você pode até receber hits de listas de discussão arquivadas ou grupos de notícias que você não conhecia ou que não pensou em pesquisar.</para>
      </listitem>

      <listitem>
	<para>Em seguida, faça uma pesquisa no <link xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">banco de dados de Relatórios de Problemas do FreeBSD</link> (Bugzilla). A menos que o problema seja recente ou obscuro, há uma boa chance de que ele já tenha sido relatado.</para>
      </listitem>

      <listitem>
	<para>Mais importante ainda, tente verificar se a documentação existente não endereça o seu problema.</para>

	<para>Para o código fonte do FreeBSD, você deve estudar cuidadosamente o conteúdo do  <filename>/usr/src/UPDATING</filename> em seu sistema ou a última versão disponível em <uri xlink:href="https://svnweb.freebsd.org/base/head/UPDATING?view=log"> https://svnweb.freebsd.org/base/head/UPDATING?view=log</uri>. (Esta é uma informação vital se você estiver atualizando de uma versão para outra - especialmente se você estiver atualizando para a Branch FreeBSD-CURRENT).</para>

	<para>No entanto, se o problema estiver em algo que foi instalado como parte da coleção de ports do FreeBSD, você deve consultar <filename>/usr/ports/UPDATING</filename> (para ports individuais) ou <filename>/usr/ports/CHANGES</filename> (para alterações que afetam toda a coleção de ports). O <uri xlink:href="https://svnweb.freebsd.org/ports/head/UPDATING?view=log">https://svnweb.freebsd.org/ports/head/UPDATING?view=log</uri> e o <uri xlink:href="https://svnweb.freebsd.org/ports/head/CHANGES?view=log">https://svnweb.freebsd.org/ports/head/CHANGES?view=log</uri> também estão disponíveis via svnweb.</para>
      </listitem>
    </itemizedlist>
  </section>

  <section xml:id="pr-writing">
    <title>Escrevendo o Relatório do Problema</title>

    <para>Agora que você decidiu que seu problema merece um relatório de problema e que ele é um problema especifico do FreeBSD, é hora de escrever o relatório de problema. Antes de entrarmos na mecânica do sistema utilizado para gerar e enviar os PRs, aqui estão algumas dicas e truques para ajudar a garantir que seu o PR seja mais eficaz.</para>

    <section xml:id="pr-writing-tips">
      <title>Dicas e Truques para Escrever um Bom Relatório de Problemas</title>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Não deixe a linha <quote>Synopsis</quote> (Sinopse) vazia. </emphasis>Os PRs são enviados para listas de discussão no mundo todo (nas quais <quote>Synopsis</quote> é usado para na linha de <literal>Subject:</literal>), além 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 pulá-lo. Lembre-se que os PRs permanecem na base de dados até que sejam fechados por alguém; os anônimos normalmente irão desaparecer em meio ao ruído.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Evite usar uma <quote>Sinopse</quote> (Sinopse) fraca. </emphasis> Você não deve presumir que alguém que esteja lendo seu PR conheça o contexto que motivou o seu envio, desta forma, quanto mais informação você fornecer, melhor. Por exemplo, a parte do sistema o problema se aplica? O problema ocorre durante a instalação ou durante a execução do sistema? Para ilustrar, em vez de usa <literal>Sinopse: o portupgrade está quebrado</literal>, veja o quanto mais informativo isso parece: <literal> Sinopse: port ports-mgmt/portupgrade gerando coredumps on -current</literal>. (No caso de um port, é especialmente útil ter tanto o nome da categoria quanto o nome do port na linha <quote>Sinopse</quote>.)</para>
	</listitem>

	<listitem>
	  <para><emphasis>Se você tem um patch, mencione-o.</emphasis> Um PR com um patch incluído é muito mais provável de ser analisado do que um sem. Se você está incluindo um, coloque a palavra <literal>[patch]</literal> (incluindo os colchetes) no início da linha de <quote>Sinopse</quote>. (Embora não seja obrigatório usar exatamente essa palavra, por convenção, essa é a que é usada.)</para>
	</listitem>

	<listitem>
	  <para><emphasis>Se você é um mantenedor, diga.</emphasis> Se você está mantendo uma parte do código fonte (por exemplo, um port), você pode considerar adicionar as palavras <literal>[atualização do mantenedor]</literal> (incluindo os colchetes) no início da sua linha de sinopse, e você definitivamente deve definir a <quote>Class</quote> (Classe) do seu PR para <literal>maintainer-update</literal>. Desta forma, qualquer committer que lide com seu PR não terá que verificar o Makefile do port, para certificar-se de que a atualização foi enviada pelo maintainer.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Seja específico.</emphasis> Quanto mais informações você fornecer sobre o problema que está tendo, maiores serão suas chances de obter uma resposta.</para>

	  <itemizedlist>
	    <listitem>
	      <para>Inclua a versão do FreeBSD que você está utilizando (há um lugar para colocar essa informação, veja abaixo) e em qual arquitetura. Você deve incluir se você está executando a partir de uma release (por exemplo, de um <acronym>CD-ROM</acronym> ou feito um download), ou de um sistema mantido pelo Subversion (e, caso seja afirmativo, em qual número de revisão você está). Se você estiver utilizando a branch FreeBSD-CURRENT, essa é a primeira coisa que alguém vai perguntar, porque as correções (especialmente para problemas de alto nível) tendem a ser realizadas muito rapidamente, e é esperado que usuários do FreeBSD-CURRENT se mantenham atualizados.</para>
	    </listitem>

	    <listitem>
	      <para>Inclua quais opções globais você especificou em seu <filename>make.conf</filename>. Nota: sabemos que especificar <literal>-O2</literal> e acima com o <citerefentry><refentrytitle>gcc</refentrytitle><manvolnum>1</manvolnum></citerefentry> gera bugs em muitas situações. Embora os desenvolvedores do FreeBSD aceitem patches, eles geralmente não estarão dispostos a investigar tais problemas devido a simples falta de tempo e de voluntários, ao invés disso podem apenas responder que isso simplesmente não é suportado.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema puder ser reproduzido facilmente, inclua informações que irão ajudar um desenvolvedor a reproduzi-lo. Se um problema puder ser demonstrado com uma entrada específica, então inclua um exemplo desta entrada se possível, e inclua tanto a saída real quanto a esperada. Se esses dados forem grandes ou não puderem ser tornados públicos, então tente criar um arquivo pequeno que exiba o mesmo problema e que possa ser incluído no PR.</para>
	    </listitem>

	    <listitem>
	      <para>Se este for um problema do kernel, esteja preparado para fornecer as seguintes informações. (Você não precisa incluí-las por padrão, o que apenas tende a preencher o banco de dados, mas você deve incluir os trechos que considera ser relevantes):</para>

	      <itemizedlist>
		<listitem>
		  <para>sua configuração do kernel (incluindo quais dispositivos de hardware você tem instalado)</para>
		</listitem>

		<listitem>
		  <para>independente de você ter ou não opções de debug habilitadas (como <literal>WITNESS</literal>), e se tiver, se o problema persiste quando você muda o sentido da opção</para>
		</listitem>

		<listitem>
		  <para>o texto completo de qualquer backtrace, panic ou outra mensagens de console, ou registros em <filename>/var/log/messages</filename>, se houver sido gerado</para>
		</listitem>

		<listitem>
		  <para>a saída de <command>pciconf -l</command> e partes relevantes da saída do comando <command>dmesg</command> se o seu problema estiver relacionado a uma peça específica de hardware</para>
		</listitem>

		<listitem>
		  <para>o fato de você ter lido <filename>src/UPDATING</filename> e o seu problema não estar listado lá (alguém pode perguntar)</para>
		</listitem>

		<listitem>
		  <para>independente de você poder executar qualquer outro kernel como um fallback (isso é para descartar problemas relacionados a hardware, como discos com falhas e CPUs superaquecidas, que podem se passar por problemas de kernel)</para>
		</listitem>
	      </itemizedlist>
	    </listitem>

	    <listitem>
	      <para>Se este for um problema de algum port, esteja preparado para fornecer as seguintes informações. (Você não precisa incluí-las por padrão, o que apenas tende a preencher o banco de dados, mas você deve incluir trechos que você considera relevantes):</para>

	      <itemizedlist>
		<listitem>
		  <para>quais ports você instalou</para>
		</listitem>

		<listitem>
		  <para>quaisquer variáveis de ambiente que sobreescrevem as variáveis padrões em <filename>bsd.port.mk</filename>, assim como <varname>PORTSDIR</varname></para>
		</listitem>

		<listitem>
		  <para>o fato de você ter lido <filename>ports/UPDATING</filename> e o seu problema não estar listado lá (é garantido que alguém irá perguntar)</para>
		</listitem>
	      </itemizedlist>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Evite requisições vagas de novas funcionalidades.</emphasis> Os PRs no formato <quote>alguém realmente deve implementar algo que faz isso e aquilo</quote> têm menor probabilidade de obter resultados do que requisições muito específicas. Lembre-se, o código fonte está disponível para todos, então se você quiser uma nova funcionalidade, a melhor maneira de garantir que ela seja incluída é começar a trabalhar! Considere também o fato de que muitas coisas como essa seriam um tópico melhor para a discussão sobre <literal>freebsd-questions</literal> do que uma entrada no banco de dados de PR, como discutido acima.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Certifique-se de que ninguém mais tenha submetido um PR similar.</emphasis> Embora isso já 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 <uri xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">https://bugs.freebsd.org/bugzilla/query.cgi</uri>. (Claro, todo mundo é culpado de esquecer de fazer isso de vez em quando.)</para>
	</listitem>

	<listitem>
	  <para><emphasis> Relate um problema apenas através do Relatório de Problemas.</emphasis> Evite incluir dois ou mais problemas dentro do mesmo relatório, a menos que estejam relacionados. Ao enviar patches, evite adicionar várias funcionalidades ou corrigir multiplos bugs no mesmo PR, a menos que eles estejam intimamente relacionados - esses PRs geralmente levam mais tempo para serem resolvidos.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Evite requisições controversas.</emphasis> Se o seu PR aborda uma área que já foi controversa no passado, você provavelmente deverá estar preparado para não apenas oferecer patches, mas também justificar por que os patches são <quote>A Coisa Certa A Se Fazer </quote>. Como observado acima, uma busca cuidadosa nas listas de discussão usando os arquivos em <uri xlink:href="https://www.FreeBSD.org/search/search.html#mailinglists"> https://www.FreeBSD.org /search/search.html#mailinglists </uri> é sempre uma boa preparação.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Seja educado.</emphasis> Quase todo mundo que potencialmente irá trabalhar em seu PR é um voluntário. Ninguém gosta que digam o que eles tem que fazer quando já estão fazendo por alguma motivação que não seja o ganho monetário. É sempre bom ter isso em mente em projetos de código aberto.</para>
	</listitem>
      </itemizedlist>
    </section>

    <section xml:id="pr-writing-before-beginning">
      <title>Antes de Começar</title>

      <para>Considerações semelhantes se aplicam ao uso do <link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">formulário de envio de PR web-based (com base em web)</link>. Cuidado com as operações de recortar e colar que podem alterar o espaços em branco ou outras formatações de texto.</para>

      <para>Finalmente, se o envio for demorado, prepare o trabalho off-line para que nada seja perdido se houver um problema ao enviá-lo.</para>
    </section>

    <section xml:id="pr-writing-attaching-patches">
      <title>Anexando Patches ou Arquivos</title>

      <para>Ao anexar um patch, certifique-se de usar <option>-u</option> com <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> para criar ou unificar o diff e certificar-se de especificar os números de revisão exatos do SVN dos arquivos que você modificou para que os desenvolvedores que lerem seu relatório possam aplicá-los facilmente. Para problemas com o kernel ou com os utilitários de base, um patch para o FreeBSD-CURRENT (a branch HEAD do Subversion) é o preferido, já que todo código novo deve ser aplicado e testado lá primeiro. Após testes apropriados ou substanciais terem sido feitos, o código será mesclado/migrado para a branch FreeBSD-STABLE.</para>

      <para>Se você anexar um patch inline, em vez de um anexo, observe que o problema mais comum, de longe, é a tendência de alguns programas de email renderizar tabs como espaços, o que ira arruinar completamente qualquer coisa destinada a fazer parte de um Makefile.</para>

      <para>Não envie correções como anexos usando <command>Content-Transfer-Encoding: quoted-printable</command>. Isso irá escapar os caracteres e todo o patch se tornará inútil.</para>

      <para>Observe também que, embora a inclusão de pequenos patches em um PR geralmente esteja correto - particularmente quando eles corrigem o problema descrito no PR - patches grandes e especialmente códigos novos que podem exigir uma revisão substancial antes do commit, deveriam ser colocados em um servidor web ou FTP, e a URL deveria ser incluída no PR em vez do patch. Patches por e-mail tendem a ficar embaralhados, e quanto maior o patch, mais difícil será para as partes interessadas recuperá-lo. Além disso, postar um patch na web permite modificá-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 não são realmente excluídos, mas sim mantidos e simplesmente marcados como completos.</para>

      <para>Você também deve observar que, a menos que você especifique explicitamente o contrário em seu PR ou no próprio patch, quaisquer patches enviados por você serão considerados licenciados sob os mesmos termos do arquivo original que você modificou.</para>
    </section>

    <section xml:id="pr-writing-filling-template">
      <title>Preenchendo o Modelo</title>

      <para>Somente no modelo de e-mail, você encontrará os seguintes campos de uma única linha:</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Submeter-Id (ID do remetente):</emphasis> Não altere isso. O valor padrão de <literal>current-users</literal> está correto, mesmo se você estiver usando o FreeBSD-STABLE.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Confidential (Confidencial): </emphasis> Isto é pré-preenchido como <literal>no</literal>. Alterá-lo não faz sentido, já que não existe um relatório confidencial de problemas do FreeBSD - o banco de dados de PR é distribuído para todo mundo.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Severety (Gravidade):</emphasis> Um dos <literal>non-critical (não críticos)</literal>, <literal>serious (sério)</literal> ou <literal>critical (crítico)</literal>. Não exagere; abstenha-se de rotular seu problema como <literal>critical</literal> a menos que realmente seja (por exemplo, problemas de corrupção de dados, séria regressão da funcionalidade anterior no -CURRENT) ou <literal>serious</literal> a menos que seja algo que afetará muitos usuários (kernel entra em pane ou congela; problemas com determinados drivers de dispositivo ou utilitários do sistema). Os desenvolvedores do FreeBSD não irão necessariamente trabalhar no seu problema mais rapido se você inflar sua importância, já que há tantas outras pessoas que fizeram exatamente isso - na verdade, alguns desenvolvedores dão pouca atenção a esse campo por causa disso.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Priority (Prioridade):</emphasis> Este campo indica o quão abrangentes sejam os efeitos deste bug.</para>
	</listitem>


      </itemizedlist>

      <para>A próxima seção descreve os campos que são comuns a ambos, interface de e-mail e a <link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">interface web</link>:</para>

      <itemizedlist>
	<listitem>
	  <para xml:lang="en"><emphasis>Originator:</emphasis> Please specify your
	    real name, optionally followed by your email address in
	    angle brackets.  In the email interface, this is normally
	    prefilled with the <literal>gecos</literal> field of the
	    currently logged-in user.</para>

	  <note>
	    <para>O endereço de e-mail que você usa se tornará publico e poderá se tornar disponível para spammers. Você deve ter procedimentos de tratamento de spam ou usar uma conta de email temporária. No entanto, observe que, se você não usar uma conta de e-mail válida, não poderemos fazer perguntas sobre seu PR.</para>
	  </note>
	</listitem>

	<listitem>
	  <para><emphasis>Organization (Organização):</emphasis> O que você quiser. Este campo não é usado para nada significativo.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Synopsis (Sinopse):</emphasis> Preencha com uma descrição breve e precisa do problema. A sinopse é usada como assunto do email do relatório de problemas. A sinopse é usada em listagens e resumos de relatórios de problemas; relatórios de problemas com sinopses obscuras tendem a ser ignoradas.</para>

	  <para>Como mencionado acima, se o seu relatório de problemas incluir um patch, faça com que a sinopse comece com <literal>[patch]</literal> (incluindo os colchetes); se este for um PR de um ports que você for o mantenedor, você pode considerar adicionar <literal>[maintainer update]</literal> (incluindo os colchetes) e definir a <quote>Class (Classe)</quote> do seu PR para <literal>maintainer-update</literal>.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Category (Categoria):</emphasis> Escolha uma categoria apropriada.</para>

	  <para>A primeira coisa que você precisa fazer é decidir em que parte do sistema está seu problema. Lembre-se, o FreeBSD é um sistema operacional completo, que instala tanto um kernel, bibliotecas padrão, muitos drivers de periféricos e um grande número de utilitários (o <quote>sistema básico</quote>). No entanto, existem milhares de aplicativos adicionais na coleção de portes. Você primeiro precisa decidir se o problema está no sistema básico ou algo instalado via a Coleção de Ports.</para>

	  <para>Aqui está uma descrição das categorias principais:</para>

	  <itemizedlist>
	    <listitem>
	      <para>Se um problema for com o kernel, as bibliotecas (como a biblioteca C padrão <literal>libc</literal>), ou o driver de algum periférico no sistema base, em geral você irá usar a categoria <literal>kern</literal>. (Existem algumas exceções; veja abaixo). Em geral, são coisas descritas nas seções 2, 3 ou 4 das páginas de manual.</para>
	    </listitem>

	    <listitem>
	      <para>Se for um problema com um programa binário, como o <citerefentry> <refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> ou o <citerefentry><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, primeiro você irá precisar determinar se esses programas estão no sistema base ou se foram adicionados por meio da Coleção de Ports. Se não tiver certeza, você pode executar o <command>whereis<replaceable> nome do programa</replaceable></command>. A convenção do FreeBSD para a Coleção de Ports é instalar tudo no diretório <filename class="directory">/usr/local</filename>, embora isso possa ser substituído por um administrador do sistema. Para estes, você usará a categoria <literal>ports</literal> (sim, mesmo se a categoria do port for <literal>www</literal>; veja abaixo). Se a localização for no diretório <filename class="directory">/bin</filename>, <filename class="directory">/usr/bin</filename>, <filename class="directory">/sbin</filename> , ou <filename class="directory">/usr/sbin</filename>, faz parte do sistema base, e você deve usar a categoria <literal>bin</literal>. (Alguns programas, como o <citerefentry><refentrytitle>gcc</refentrytitle><manvolnum>1</manvolnum></citerefentry>, na verdade usam a categoria <literal>gnu</literal>, mas não se preocupe com isso por enquanto.) Estas são todas as coisas descritas na seção 1 ou 8 das páginas do manual.</para>
	    </listitem>

	    <listitem>
	      <para>Se você acredita que o erro está nos scripts de inicialização <literal>(rc)</literal>, ou em algum outro tipo de arquivo de configuração não-executável, então a categoria correta é <literal>conf</literal> (configuração) . Estas são as coisas descritas na seção 5 das páginas de manual.</para>
	    </listitem>

	    <listitem>
	      <para>Se você encontrou um problema no conjunto de documentação (artigos, livros, man pages), a escolha correta é <literal>docs</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se você estiver tendo um problema com as <link xlink:href="http://www.FreeBSD.org">páginas web do FreeBSD</link>, a escolha apropriada é <literal>www</literal>.</para>

	      <note>
		<para>Se você estiver tendo um problema com algum port chamado <literal>www/<replaceable>algum nome de port</replaceable></literal>, mesmo assim, isso vai na categoria <literal>ports</literal>.</para>
	      </note>
	    </listitem>
	  </itemizedlist>

	  <para>Existem algumas categorias mais especializadas.</para>

	  <itemizedlist>
	    <listitem>
	      <para>Se o problema, por outro lado, estar colocado em <literal>kern</literal>, mas tem a ver com o subsistema USB, a escolha correta é <literal>usb</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema, por outro lado, estiver colocado em <literal>kern</literal>, mas tem a ver com as bibliotecas de threads, a escolha correta é <literal>threads</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema, por outro lado, estiver no sistema base, mas tem a ver com nossa fidelidade a padrões como <trademark class="registered">POSIX</trademark>, a escolha correta é <literal>standards</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema for relacionado a erros internos de uma <trademark>Java Virtual Machine</trademark> (<trademark>JVM</trademark> Maquina Virtual do Java), mesmo que o <trademark>Java</trademark> tenha sido instalado a partir da coleção de ports, deve ser selecionada a categoria <literal>java</literal>. Problemas mais gerais com os ports <trademark>Java</trademark> ainda irão estar em <literal>ports</literal>.</para>
	    </listitem>
	  </itemizedlist>

	  <para>Isso deixa tudo mais.</para>

	  <itemizedlist>
	    <listitem>
	      <para>Se estiver convencido de que o problema ocorrerá apenas sob a arquitetura do processador que você está usando, selecione uma das categorias específicas da arquitetura: geralmente <literal>i386</literal> para máquinas compatíveis com Intel 32 bits; <literal>amd64</literal> para máquinas AMD rodando em de 64 bits (isto também inclui máquinas compatíveis com Intel rodando em modo EMT64); e menos comum, as arquiteturas <literal>arm</literal>, <literal>ia64</literal>, <literal>powerpc</literal> e <literal>sparc64</literal>.</para>

	      <note>
		<para>Estas categorias são muitas vezes mal utilizadas para problemas definidos como <quote>Eu não sei</quote>. Em vez de adivinhar, por favor use apenas <literal>misc</literal>.</para>
	      </note>

	      <example>
		<title>Uso Correto da Categoria Específica de Arquitetura</title>

		<para>Você tem uma máquina comum baseada em PC e acha que encontrou um problema específico para um determinado chipset ou uma placa-mãe em particular: <literal>i386</literal> é a categoria correta.</para>
	      </example>

	      <example>
		<title>Uso Incorreto da Categoria Específica de Arquitetura</title>

		<para>Você está tendo um problema com uma placa periférica adicional em um barramento comum, ou um problema com um tipo específico de unidade de disco rígido: neste caso, provavelmente se aplica a mais de uma arquitetura, e <literal>kern</literal> é a categoria correta.</para>
	      </example>
	    </listitem>

	    <listitem>
	      <para>Se você realmente não sabe onde o problema se encaixa (ou a explicação não parece se encaixar nos itens acima), use a categoria <literal>misc</literal>. Antes de fazer isso, você pode pedir ajuda primeiro na <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions">lista de discussão de perguntas gerais do FreeBSD</link>. Você pode ser avisado que com certeza uma das categorias existentes é uma escolha melhor.</para>
	    </listitem>
	  </itemizedlist>

	  <para>Aqui está a lista atual de categorias atual (retiradas de <uri xlink:href="https://svnweb.freebsd.org/base/head/gnu/usr.bin/send-pr/categories">https://svnweb.freebsd.org/base/head/gnu/usr.bin/send-pr/categories</uri>):</para>

	  <itemizedlist>
	    <listitem>
	      <para><literal> advocacy: </literal> problemas relacionados à imagem pública do FreeBSD. Obsoleto.</para>
	    </listitem>

	    <listitem>
	      <para><literal>amd64:</literal> problemas específicos da plataforma AMD64.</para>
	    </listitem>

	    <listitem>
	      <para><literal>arm:</literal> problemas específicos da plataforma ARM.</para>
	    </listitem>

	    <listitem>
	      <para><literal>bin:</literal> problemas com programas em espaço de usuário no sistema base.</para>
	    </listitem>

	    <listitem>
	      <para><literal>conf:</literal> problemas com arquivos de configuração, valores padrão e assim por diante.</para>
	    </listitem>

	    <listitem>
	      <para><literal>docs:</literal> problemas com páginas de manual ou documentação on-line.</para>
	    </listitem>

	    <listitem>
	      <para><literal>gnu:</literal> problemas com software GNU importado, como <citerefentry><refentrytitle>gcc</refentrytitle><manvolnum>1</manvolnum></citerefentry> ou <citerefentry><refentrytitle>grep</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
	    </listitem>

	    <listitem>
	      <para><literal>i386:</literal> problemas específicos da plataforma <trademark>i386</trademark>.</para>
	    </listitem>

	    <listitem>
	      <para><literal>ia64:</literal> problemas específicos da plataforma ia64.</para>
	    </listitem>

	    <listitem>
	      <para><literal>java:</literal> problemas relacionados à máquina virtual do <trademark>Java</trademark>.</para>
	    </listitem>

	    <listitem>
	      <para><literal>kern:</literal> problemas com o kernel, drivers de dispositivos (sem-plataforma-especifica) ou as bibliotecas da base.</para>
	    </listitem>

	    <listitem>
	      <para><literal>misc:</literal> qualquer coisa que não se encaixe em nenhuma das outras categorias. (Note que não há quase nada que realmente pertença a esta categoria, exceto por problemas com a infraestrutura de release e build. Falhas de compilação temporárias na branch <literal>HEAD</literal> não pertencem a essa categoria. Note também que é fácil para as coisas se perderem nessa categoria).</para>
	    </listitem>

	    <listitem>
	      <para><literal>ports:</literal> problemas relacionados à Coleção de Ports.</para>
	    </listitem>

	    <listitem>
	      <para><literal>powerpc:</literal> problemas específicos da plataforma <trademark class="registered">PowerPC</trademark>.</para>
	    </listitem>

	    <listitem>
	      <para><literal>sparc64:</literal> problemas específicos da plataforma <trademark class="registered">SPARC64</trademark>.</para>
	    </listitem>

	    <listitem>
	      <para><literal>standards:</literal> problemas de conformidade de padrões.</para>
	    </listitem>

	    <listitem>
	      <para><literal>threads:</literal> problemas relacionados a implementação de threads do FreeBSD (especialmente no FreeBSD-CURRENT).</para>
	    </listitem>

	    <listitem>
	      <para><literal>usb:</literal> problemas relacionados à implementação de USB no FreeBSD.</para>
	    </listitem>

	    <listitem>
	      <para><literal>www:</literal> alterações ou melhorias no site do FreeBSD.</para>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Class:</emphasis> Escolha uma das seguintes opções:</para>

	  <itemizedlist>
	    <listitem>
	      <para><literal>sw-bug:</literal> bugs em software.</para>
	    </listitem>

	    <listitem>
	      <para><literal>doc-bug:</literal> bugs na documentação.</para>
	    </listitem>

	    <listitem>
	      <para><literal>change-request:</literal> requisições para recursos adicionais ou alterações em recursos existentes.</para>
	    </listitem>

	    <listitem>
	      <para><literal>update:</literal> atualizações para ports ou outra atribuição de software.</para>
	    </listitem>

	    <listitem>
	      <para><literal>maintainer-update:</literal> atualização para ports que você é o mantenedor.</para>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Release:</emphasis> A versão do FreeBSD que você está executando. Isto precisa ser preenchido.</para>
	</listitem>
      </itemizedlist>

      <para>Finalmente, aqui está uma série de campos com várias linhas:</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Environment:</emphasis> Isto deve descrever, com a maior precisão possível, o ambiente em que o problema foi observado. Isto inclui a versão do sistema operacional, a versão do programa ou arquivo específico que contém o problema e quaisquer outros itens relevantes, como configuração 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.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Description:</emphasis> Uma descrição completa e precisa do problema que você está enfrentando. Tente evitar especular sobre as causas do problema, a menos que tenha certeza de que você está no caminho certo, pois isso pode induzir o desenvolvedor a fazer suposições incorretas sobre o problema.</para>
	</listitem>

	<listitem>
	  <para><emphasis>How-To-Repeat:</emphasis> Um resumo das ações que você precisa realizar para reproduzir o problema.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Fix:</emphasis> De preferência um patch, ou pelo menos uma solução alternativa (que não só ajuda outras pessoas com o mesmo problema a contorná-lo, mas também pode ajudar um desenvolvedor a entender a causa do problema), mas se você não tem idéias firmes para nenhum dos dois, é melhor deixar esse campo em branco do que especular.</para>
	</listitem>
      </itemizedlist>
    </section>

    <section xml:id="pr-writing-sending">
      <title>Enviando o Relatório de Problemas</title>

      <para>Se você estiver usando o <link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">formulário web</link>:</para>

      <para>Antes de clicar em <literal>submit</literal>, você irá precisar preencher um campo contendo um texto que é representado em forma de imagem na página. Esta infeliz medida teve que ser adotada devido ao uso indevido por sistemas automatizados e alguns indivíduos mal orientados. É um mal necessário que ninguém gosta; por favor, não nos peça para removê-lo.</para>

      <para>Note que é <literal>fortemente recomendado</literal> salvar seu trabalho em algum lugar antes de clicar em <literal>submit</literal>. Um problema comum para os usuários é ter seu navegador web exibindo uma imagem obsoleta de seu cache. Se isso acontecer com você, seu envio será rejeitado e você poderá perder seu trabalho.</para>

      <para>Se você não conseguir ver as imagens por qualquer motivo, aceite nossas desculpas pelo inconveniente e envie seu relatório por e-mail para a equipe do bugbuster através de <email>freebsd-bugbusters@FreeBSD.org</email>.</para>
    </section>
  </section>

  <section xml:id="pr-followup">
    <title>Acompanhamento</title>

    <para>Uma vez que o relatório de problema foi colocado na fila, você receberá uma confirmação por e-mail que incluirá o número de rastreamento que foi atribuído ao seu relatório de problema e uma URL que você pode usar para verificar seu status. Com um pouco de sorte, alguém se interessará por seu problema e tentará resolvê-lo, ou, conforme o caso, explicar por que isso não é um problema. Você será automaticamente notificado de qualquer alteração de status e receberá cópias de quaisquer comentários ou correções que alguém possa anexar à trilha de auditoria do seu relatório de problemas.</para>

    <para>Se alguém solicitar informações adicionais de você, lembrar ou descobrir algo que você não mencionou no relatório inicial, por favor, adicione um novo comentário de acompanhamento. O motivo número um para um bug não ser corrigido é a falta de comunicação com o criador do relatório.</para>

    <itemizedlist>
      <listitem>
	<para>A maneira mais fácil é usar a opção de comentário na página web do PR individual, que você pode acessar na <link xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">página de pesquisa de PR</link>.</para>
      </listitem>
    </itemizedlist>

    <para>Se o relatório de problemas permanecer aberto após o desaparecimento do problema, basta adicionar um comentário dizendo que o relatório de problemas pode ser fechado e, se possível, explicar como ou quando o problema foi corrigido.</para>

    <para>As vezes, há um atraso de uma semana ou duas em que o relatório do problema permanece intocado, não atribuído ou comentado por alguém. Isto pode acontecer quando há um aumento na lista de pendências de relatórios de problemas ou durante uma temporada de feriados. Quando um relatório de problema não recebe atenção após várias semanas, vale a pena encontrar um committer particularmente interessado em trabalhar nele.</para>

    <para>Existem algumas maneiras de se fazer isso, idealmente na seguinte ordem, com alguns dias entre a tentativa em cada canal de comunicação:</para>

    <itemizedlist>
      <listitem>
	<para>Encontre a lista de discussão relevante do FreeBSD para o relatório de problemas <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">listadas no Handbook</link> e envie uma mensagem para essa lista perguntando sobre assistência ou comentários sobre o relatório do problema.</para>
      </listitem>

      <listitem>
	<para>Junte-se aos canais relevantes do <acronym>IRC</acronym>. Uma lista parcial está aqui: <link xlink:href="https://wiki.freebsd.org/IrcChannels"/>. Informe as pessoas nesse canal sobre o relatório de problemas e peça ajuda. Seja paciente e fique no canal depois de postar, para que as pessoas de diferentes fusos horários ao redor do mundo tenham a chance de responder.</para>
      </listitem>

      <listitem>
	<para>Encontre committers interessados no problema que foi relatado. Se o problema estiver em uma ferramenta, binário, porta, documento ou arquivo fonte específico, verifique o <link xlink:href="http://svnweb.FreeBSD.org">Repositório SVN</link>. Localize os últimos committers que fizeram alterações substanciais no arquivo e tente falar com eles pelo <acronym>IRC</acronym> ou por email. Uma lista de committers e seus e-mails podem ser encontrados no artigo <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributors">Contributors do FreeBSD</link>.</para>
      </listitem>
    </itemizedlist>

    <para>Lembre-se de que essas pessoas são voluntárias, assim como mantenedores e usuários, portanto, podem não estar disponíveis imediatamente para ajudar no relatório de problemas. Paciência e consistência nos acompanhamentos são altamente recomendados e apreciados. Com cuidado e esforço suficientemente dedicados a esse processo de acompanhamento, encontrar um committer para cuidar do relatório do problema é apenas uma questão de tempo.</para>
  </section>

  <section xml:id="pr-problems">
    <title>Se Existir Problemas</title>

    <para>Se você encontrou um problema com o sistema de bugs, registre um bug! Existe uma categoria exatamente para esse propósito. Se você não conseguir, entre em contato com os organizadores do bug em <email>bugmeister@FreeBSD.org</email>.</para>
  </section>

  <section xml:id="pr-further">
    <title>Leitura Adicional</title>

    <para>Esta é uma lista de recursos relevantes para a escrita adequada e processamento de relatórios de problemas. Não está de modo algum completo.</para>

    <itemizedlist>
      <listitem>
	<para><link xlink:href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">Como reportar bugs efetivamente</link> -um excelente ensaio de Simon G. Tatham sobre compor de forma util relatórios de problemas (não específicos do FreeBSD).</para>
      </listitem>

      <listitem>
	<para><link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/pr-guidelines/article.html">Orientações para o tratamento dos relatórios de problemas</link> —informações valiosas sobre como os relatórios de problemas são tratados pelos desenvolvedores do FreeBSD.</para>
      </listitem>
    </itemizedlist>
  </section>

  <index/>
</article>