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

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
        "../../../share/sgml/freebsd42.dtd" [
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//PT" "../../share/sgml/entities.ent">
%entities;
]>

<!--
  The FreeBSD Documentation Project
  The FreeBSD Brazilian Portuguese Documentation Project

  Original revision: r39487
-->

<article>
  <articleinfo>
    <title>Escrevendo Relat&oacute;rios de Problema no &os;</title>

    <pubdate>$FreeBSD$</pubdate>

    <legalnotice id="trademarks" role="trademarks">
      &tm-attrib.freebsd;
      &tm-attrib.cvsup;
      &tm-attrib.ibm;
      &tm-attrib.intel;
      &tm-attrib.sparc;
      &tm-attrib.sun;
      &tm-attrib.general;
    </legalnotice>

    <abstract>
      <para>Este artigo descreve qual a melhor forma de formular e 
	de submeter um relat&oacute;rio de problema para Projeto 
	&os;.</para>
    </abstract>

    <authorgroup>
      <author>
	<firstname>Dag-Erling</firstname>
	<surname>Sm&oslash;rgrav</surname>
	<contrib>Contribuido por</contrib>
      </author>

      <author>
	<firstname>Mark</firstname>
	<surname>Linimon</surname>
      </author>
    </authorgroup>
  </articleinfo>

  <indexterm><primary>relat&oacute;rio de problema</primary>
    </indexterm>

  <section id="pr-intro">
    <title>Introdu&ccedil;&atilde;o</title>

    <para>Uma das experi&ecirc;ncias mais frustrantes que
      algu&eacute;m pode ter como um usu&aacute;rio de um software
      &eacute; submeter um relat&oacute;rio sobre um problema 
      que est&aacute; enfrentando apenas para v&ecirc;-lo ser 
      sumariamente fechado com uma informa&ccedil;&atilde;o curta
      e pouco &uacute;til do tipo <quote>isto n&atilde;o &eacute; 
      um bug</quote> ou ainda <quote>este relat&oacute;rio de 
      problema n&atilde;o procede</quote>.  Da mesma forma, uma das 
      experi&ecirc;ncias mais frustrantes para um desenvolvedor de 
      software &eacute; ser inundado com relat&oacute;rios de 
      problemas que na verdade n&atilde;o s&atilde;o realmente 
      relat&oacute;rios de problemas, mas sim 
      solicita&ccedil;&otilde;es de suporte, ou ent&atilde;o que 
      contenham pouca ou nenhuma informa&ccedil;&atilde;o sobre como
      o problema ocorre e sobre como proceder para 
      reproduzi-lo.</para>
    
    <para>Este documento tem por objetivo descrever como escrever 
      bons relat&oacute;rios de problema.  Mas o que vem a ser um 
      bom relat&oacute;rio de problema?  Bem, indo direto ao ponto,
      um bom relat&oacute;rio de problema &eacute; aquele que se 
      pode analisar e tratar rapidamente, para a 
      satisfa&ccedil;&atilde;o m&uacute;tua do usu&aacute;rio e do 
      desenvolvedor.</para>
    
    <para>Embora o foco prim&aacute;rio deste artigo seja a
      elabora&ccedil;&atilde;o de relat&oacute;rios de problemas no
      &os;, a maior parte das recomenda&ccedil;&otilde;es deve
      aplicar-se muito bem a outros projetos de software.</para>
    
    <para>Observe que este artigo esta organizado de forma
      tem&aacute;tica, e n&atilde;o de forma cronol&oacute;gica, 
      desta forma voc&ecirc; deve ler o documento inteiro antes 
      de enviar um relat&oacute;rio de problema, ao inv&eacute;s 
      de trat&aacute;-lo como um tutorial passo-a-passo.</para>
  </section>

  <section id="pr-when">
    <title>Quando enviar um relat&oacute;rio de problema</title>

    <para>Existem muitos tipos de problemas, e nem todos eles devem
      gerar um relat&oacute;rio de problema.  &Eacute; claro,
      ningu&eacute;m &eacute; perfeito e em algumas ocasi&otilde;es
      voc&ecirc; ter&aacute; certeza de que encontrou um bug em um
      determinado software quando na verdade voc&ecirc; compreendeu 
      errado a sintaxe de um comando ou mesmo cometeu um erro de
      digita&ccedil;&atilde;o em um arquivo de 
      configura&ccedil;&atilde;o (o que por sua vez pode indicar 
      uma documenta&ccedil;&atilde;o pouco detalhada ou
      ent&atilde;o um tratamento inadequado do erro por parte
      da aplica&ccedil;&atilde;o).  Existem ainda muitas outras
      situa&ccedil;&otilde;es nas quais enviar um relat&oacute;rio de
      problema claramente <emphasis>n&atilde;o</emphasis> &eacute; 
      a melhor a&ccedil;&atilde;o a ser tomada, e s&oacute; vai 
      servir para frustrar a voc&ecirc; e aos desenvolvedores.  Em 
      contrapartida, existem situa&ccedil;&otilde;es nas quais 
      &eacute; recomendado que voc&ecirc; nos envie um 
      relat&oacute;rio de problema sobre outras coisas que 
      n&atilde;o um bug, como por exemplo para nos enviar uma 
      sugest&atilde;o de melhoria ou um pedido de uma nova
      funcionalidade.</para>
    
    <para>Ent&atilde;o como voc&ecirc; ir&aacute; diferenciar o que 
      &eacute; e o que n&atilde;o &eacute; um bug?  Existe uma regra
      de ouro que diz que o seu problema <emphasis>n&atilde;o
      &eacute;</emphasis> um bug se ele pode ser expresso como uma
      pergunta (normalmente na forma <quote>Como eu fa&ccedil;o
      X</quote> ou <quote>Onde eu posso encontrar Y</quote>).  Na 
      maior parte das vezes n&atilde;o ser&aacute; sempre
      t&atilde;o claro desta forma, mas a regra acima cobre a grande
      maioria dos casos.  Se voc&ecirc; estiver procurando por uma
      resposta, considere enviar a sua pergunta para
      &a.questions;.</para>
    
    <para>Veja alguns casos nos quais pode ser apropriado enviar um
      relat&oacute;rio de problema sobre algo que n&atilde;o &eacute;
      um bug:</para>

    <itemizedlist>
      <listitem>
	<para>Pedidos de melhorias nas funcionalidades.  Geralmente
	&eacute; uma boa id&eacute;ia debater estas propostas nas
	listas de discuss&atilde;o antes de envi&aacute;-las em um
	relat&oacute;rio de problemas.</para>
      </listitem>

      <listitem>
	<para>Notifica&ccedil;&otilde;es sobre
	  atualiza&ccedil;&otilde;es de softwares mantidos
	  externamente (principalmente do ports, mas tamb&eacute;m
	  de componentes do sistema base como, por exemplo, o BIND e
	  v&aacute;rios outros utilit&aacute;rios GNU).</para>

	<para>Para os ports sem manuten&ccedil;&atilde;o
	  (aqueles nos quais a vari&aacute;vel 
	  <makevar>MAINTAINER</makevar> cont&eacute;m 
	  <literal>ports@FreeBSD.org</literal>), essas
	  notifica&ccedil;&otilde;es de atualiza&ccedil;&atilde;o 
	  podem ser capturadas por um <literal>committer</literal>
	  interessado, ou voc&ecirc; pode ser solicitado a fornecer 
	  um <literal>patch</literal> para atualizar o port;
	  disponibilizar este <literal>patch</literal> antecipadamente
	  ir&aacute; melhorar de forma significativa as suas chances
	  de ter o port atualizado rapidamente.</para>

	<para>Se o port possui um mantenedor, o envio de um
	  relat&oacute;rio de problema comunicando sobre o
	  lan&ccedil;amento de uma nova vers&atilde;o geralmente
	  n&atilde;o &eacute; muito &uacute;til uma vez que eles geram
	  trabalho adicional para os <literal>committers</literal>,
	  e o mantenedor provavelmente j&aacute; tem conhecimento de
	  que existe uma nova vers&atilde;o, ele provavelmente
	  j&aacute; trabalhou com os desenvolvedores para
	  atualiz&aacute;-lo e est&aacute; provavelmente executando
	  testes para verificar se n&atilde;o existem problemas,
	  etc.</para>
	
	<para>Em ambos os casos, voc&ecirc; ir&aacute; obter melhores
	  resultados se seguir o processo descrito no <ulink 
	  url="&url.books.porters-handbook;/port-upgrading.html">Porter's Handbook</ulink>.
	  (Talvez voc&ecirc; tamb&eacute;m queira ler o artigo <ulink 
	  url="&url.articles.contributing-ports;/article.html">
	  Contribuindo para a Cole&ccedil;&atilde;o de Ports 
	  do &os;</ulink>.)</para>
      </listitem>
    </itemizedlist>

    <para>Um bug que n&atilde;o pode ser reproduzido, raramente
      ser&aacute; corrigido.  Se o bug ocorreu uma &uacute;nica
      vez e voc&ecirc; n&atilde;o consegue reproduzi-lo, e
      se aparentemente ele n&atilde;o ocorre com mais ningu&eacute;m,
      as chances s&atilde;o de que nenhum dos desenvolvedores
      ser&aacute; capaz de reproduzir ou de saber o que est&aacute; 
      errado.  Isso n&atilde;o significa que n&atilde;o seja
      poss&iacute;vel, mas significa que a probabilidade do seu
      relat&oacute;rio de problema resultar na corre&ccedil;&atilde;o
      do bug &eacute; muito pequena.  Para piorar a
      situa&ccedil;&atilde;o, muitas vezes este tipo de erro
      &eacute;, na realidade, causado por falhas nos discos 
      r&iacute;gidos ou por superaquecimento do processador &mdash;
      sempre que poss&iacute;vel voc&ecirc; deve tentar excluir estas
      causas antes de enviar um relat&oacute;rio de problema.</para>

    <para>Em seguida, para decidir a quem voc&ecirc; deve apresentar 
      o seu relat&oacute;rio de problema, voc&ecirc; precisa 
      entender que o &os; &eacute; composto de v&aacute;rios 
      elementos de software diferentes:</para>
    
    <itemizedlist>
      <listitem>
	<para>C&oacute;digo na base do sistema que &eacute; escrito 
	  e mantido por colaboradores do &os;, tais como o Kernel, a
	  biblioteca C, os drivers de dispositivos (categorizados 
	  como <literal>kern</literal>); os utilit&aacute;rios
	  bin&aacute;rios (<literal>bin</literal>); as p&aacute;ginas
	  de manual e a documenta&ccedil;&atilde;o
	  (<literal>docs</literal>); e as p&aacute;ginas web
	  (<literal>www</literal>).  Todos os bugs nestas 
	  &aacute;reas devem ser reportados para os desenvolvedores 
	  do &os;</para>
      </listitem>

      <listitem>
	<para>C&oacute;digo na base do sistema que &eacute; escrito 
	  e mantido por outros, e que foram adaptados e importados 
	  no &os;.  Exemplos incluen <application>bind</application>,
	  &man.gcc.1;, e &man.sendmail.8;.  A maioria dos bugs nestas
	  &aacute;reas devem ser reportados para os desenvolvedores do
	  &os;; mas em alguns casos pode ser necess&aacute;rio
	  report&aacute;-los aos autores originais, caso o problema
	  n&atilde;o seja especifico do &os;.  Normalmente estes bugs
	  ir&atilde;o ficar sob as categorias <literal>bin</literal>
	  ou <literal>gnu</literal>.</para>
      </listitem>

      <listitem>
	<para>Os aplicativos individuais que n&atilde;o est&atilde;o
	  na base do sistema, mas que fazem parte da
	  cole&ccedil;&atilde;o de Ports do &os; (Categoria
	  <literal>ports</literal>).  A maioria destes aplicativos
	  n&atilde;o s&atilde;o escritos por desenvolvedores do
	  &os;; o que o &os; oferece &eacute; apenas um sistema para
	  facilitar a instala&ccedil;&atilde;o do aplicativo.
	  Portanto, voc&ecirc; deve relatar um problema para os
	  desenvolvedores do &os; apenas quando voc&ecirc; acreditar 
	  que o problema &eacute; espec&iacute;fico do &os;, caso
	  contr&aacute;rio, voc&ecirc; deve report&aacute;-lo aos
	  autores do software.</para>
      </listitem>

    </itemizedlist>

    <para>A seguir voc&ecirc; deve verificar se o problema &eacute; 
      ou n&atilde;o atual.  Existem poucas coisas que aborrecem um
      desenvolvedor mais do que receber um relat&oacute;rio de 
      problema a respeito de um bug que ele j&aacute; corrigiu.</para>
    
    <para>Se o problema est&aacute; na base do sistema, voc&ecirc;
      dever&aacute; primeiro ler a se&ccedil;&atilde;o do FAQ sobre 
      <ulink url="&url.books.faq;/introduction.html#LATEST-VERSION">
      Vers&otilde;es do &os;</ulink>, se voc&ecirc; n&atilde;o estiver
      familiarizado com o tema.  N&atilde;o &eacute; poss&iacute;vel
      para o &os; corrigir problemas em vers&otilde;es muito antigas
      do sistema base, desta forma enviar um relat&oacute;rio de
      problema sobre um bug em uma vers&atilde;o muito antiga vai
      provavelmente resultar apenas em um desenvolvedor aconselhando
      que voc&ecirc; atualize o seu sistema para uma vers&atilde;o 
      suportada para ver se o problema ainda ocorre.  A equipe
      de <literal>Security Officer</literal> mant&eacute;m a 
      <ulink url="&url.base;/security/">lista de vers&otilde;es
      suportadas</ulink>.</para>

    <para>Se o problema est&aacute; em um port, observe que
      voc&ecirc; dever&aacute; primeiro atualizar seu sistema para a
      vers&atilde;o mais atual da cole&ccedil;&atilde;o de ports e ver
      se o problema ainda se aplica.  Devido ao ritmo acelerado de
      mudan&ccedil;as nestas aplica&ccedil;&otilde;es, &eacute;
      invi&aacute;vel para o &os; suportar qualquer coisa que
      n&atilde;o seja obrigatoriamente a vers&atilde;o mais
      recente, e problemas com uma vers&atilde;o antiga do
      aplicativo simplesmente n&atilde;o podem ser corrigidos.</para>
  </section>

  <section id="pr-prep">
    <title>Prepara&ccedil;&atilde;o</title>

    <para>Uma boa regra a ser seguida sempre &eacute; realizar uma
      busca a respeito do assunto antes de enviar um relat&oacute;rio
      de problema.  Pode ser que o seu problema j&aacute; tenha sido
      reportado anteriormente; pode ser que esteja sendo debatido nas
      listas de discuss&atilde;o ou que tenha sido recentemente; pode 
      at&eacute; ser que o problema j&aacute; tenha sido corrigido em
      uma vers&atilde;o mais recente do que a que voc&ecirc; 
      est&aacute; utilizando.  Voc&ecirc; deve portanto verificar 
      em todos os lugares &oacute;bvios antes de enviar o 
      relat&oacute;rio de problema.  Para o &os;, isto 
      significa:</para>
    
    <itemizedlist>
      <listitem>
	<para>A lista de <ulink 
	  url="&url.books.faq;/index.html">Perguntas e Respostas mais 
	  Frequentes</ulink> sobre o &os; (FAQ).  A FAQ tem por
	  objetivo fornecer respostas para uma grande variedade de
	  perguntas, tais como as que dizem respeito a <ulink
	  url="&url.books.faq;/hardware.html">compatibilidade de
	  hardware</ulink>, <ulink
	  url="&url.books.faq;/applications.html">aplica&ccedil;&otilde;es
	  do usu&aacute;rio</ulink>, <ulink
	  url="&url.books.faq;/kernelconfig.html">Configura&ccedil;&atilde;o
	  do kernel</ulink>, etc.</para>
      </listitem>

      <listitem>
	<para>As <ulink 
	  url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">
	  listas de discuss&atilde;o</ulink> &mdash; se voc&ecirc;
	  n&atilde;o est&aacute; inscrito, utilize a <ulink 
	  url="http://www.FreeBSD.org/search/search.html#mailinglists">
	  busca do hist&oacute;rico</ulink> no web site do 
	  &os;.  Se o seu problema n&atilde;o tiver sido discutido nas
	  listas, voc&ecirc; pode tentar enviar uma mensagem sobre ele
	  e aguardar alguns dias para ver se algu&eacute;m consegue
	  perceber algo que voc&ecirc; tenha deixado passar
	  desapercebido.</para>
      </listitem>

      <listitem>
	<para>Opcionalmente, na internet inteira &mdash; utilize seu
	  mecanismo de busca preferido para localizar 
	  refer&ecirc;ncias sobre o seu problema.  Voc&ecirc; pode 
	  encontrar refer&ecirc;ncias a ele em mensagens de listas de
	  discuss&atilde;o ou de grupos de noticias dos quais 
	  voc&ecirc; nunca ouviu falar ou nos quais sequer pensou 
	  em procurar.</para>
      </listitem>

      <listitem>
	<para>Na sequ&ecirc;ncia, verifique o <ulink
	  url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
	  banco de dados com os relat&oacute;rios de problema do 
	  &os;</ulink> (GNATS).  A menos que o seu problema seja 
	  recente ou muito obscuro, existe uma boa chance dele 
	  j&aacute; ter sido reportado.</para>
      </listitem>

      <listitem>
	<para>E o mais importante, voc&ecirc; deve verificar se a
	  documenta&ccedil;&atilde;o existente no c&oacute;digo base
	  n&atilde;o endere&ccedil;a o seu problema.</para>
	
	<para>Para o c&oacute;digo base do &os; voc&ecirc; deve
	  estudar cuidadosamente o conte&uacute;do do arquivo
	  <filename>/usr/src/UPDATING</filename> dispon&iacute;vel no
	  seu sistema de arquivos ou a sua vers&atilde;o mais 
	  recente no <ulink
	  url="http://svnweb.freebsd.org/base/head/UPDATING">
	  Reposit&oacute;rio Subversion</ulink>.  (Esta 
	  informa&ccedil;&atilde;o &eacute; vital se voc&ecirc; 
	  estiver atualizando de uma vers&atilde;o para outra 
	  &mdash; especialmente se estiver atualizando para o 
	  &os.current;).</para>
	
	<para>No entanto, se o problema &eacute; com algo que foi
	  instalado como uma parte da cole&ccedil;&atilde;o de ports 
	  do &os; voc&ecirc; deve consultar o 
	  <filename>/usr/ports/UPDATING</filename> (para os ports
	  individuais) ou o <filename>/usr/ports/CHANGES</filename>
	  (para mudan&ccedil;as que afetam a Cole&ccedil;&atilde;o de
	  Ports inteira).  Estes arquivos tamb&eacute;m est&atilde;o
	  dispon&iacute;veis no SVNWeb, nos urls <ulink
	  url="http://svnweb.freebsd.org/ports/head/UPDATING"></ulink>
	  e <ulink
	  url="http://svnweb.freebsd.org/ports/head/CHANGES"></ulink>
	  respectivamente.</para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="pr-writing">
    <title>Escrevendo o Relat&oacute;rio de Problema</title>

    <para>Agora que voc&ecirc; decidiu que o seu assunto merece um
      relat&oacute;rio de problema (PR), e que ele &eacute; um 
      problema do &os;, &eacute; hora de escrever o relat&oacute;rio 
      em si.  Mas antes de entrarmos na mec&acirc;nica do programa 
      utilizado para gerar e enviar os PRs, aqui est&atilde;o 
      algumas dicas e truques para ajud&aacute;-lo a garantir que o 
      seu PR ser&aacute; o mais efetivo poss&iacute;vel.</para>
    
    <section>
      <title>Dicas e truques para escrever um bom relat&oacute;rio de
	problema.</title>

      <itemizedlist>
	<listitem>
	  <para><emphasis>N&atilde;o deixe a linha de
	    <quote>Synopsis</quote> (sinopse) em branco.</emphasis>  
	    Os PRs s&atilde;o enviados para listas de discuss&atilde;o
	    no mundo todo (nas quais a <quote>Synopsis</quote> 
	    &eacute; utilizada como linha de 
	    <literal>Subject:</literal>), al&eacute;m de serem 
	    armazenados 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&aacute;-lo.  Lembre-se que os PRs
	    permanecem na base de dados at&eacute; que sejam fechados
	    por algu&eacute;m; os an&ocirc;nimos normalmente 
	    ir&atilde;o desaparecer em meio ao ru&iacute;do.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Evite utilizar uma <quote>Synopsis</quote>
	    (sinopse) fraca.</emphasis>  Voc&ecirc; n&atilde;o
	    pode assumir que algu&eacute;m que esteja lendo o seu PR 
	    conhe&ccedil;a todo o contexto que motivou o seu envio, 
	    desta forma quanto mais informa&ccedil;&atilde;o 
	    voc&ecirc; fornecer, melhor.  Por exemplo, a que 
	    parte do sistema o problema se aplica?  O problema 
	    ocorre durante a instala&ccedil;&atilde;o ou durante a
	    execu&ccedil;&atilde;o do sistema?  Para ilustrar, ao 
	    inv&eacute;s de utilizar <literal>Synopsis: o 
	    portupgrade est&aacute; quebrado</literal>, veja o 
	    qu&atilde;o mais claro e mais eficiente seria 
	    utilizar <literal>Synopsis: port sysutils/portupgrade 
	    gerando coredumps no -current</literal>. (No caso de um 
	    port, &eacute; especialmente &uacute;til ter a categoria 
	    e o nome do port na linha de sinopse.)</para>
	</listitem>

	<listitem>
	  <para><emphasis>Se voc&ecirc; possui um patch,
	    mencione-o.</emphasis>  Um PR que inclui um
	    <literal>patch</literal> &eacute; muito mais
	    prov&aacute;vel de ser analisado do que um sem.  Se
	    voc&ecirc; estiver incluindo um, coloque a palavra
	    <literal>[patch]</literal> no inicio da linha
	    de sinopse.  (Embora n&atilde;o seja obrigat&oacute;rio
	    utilizar exatamente esta palavra, por
	    conven&ccedil;&atilde;o, &eacute; ela que &eacute;
	    utilizada.)</para>
	</listitem>

	<listitem>
	  <para><emphasis>Se voc&ecirc; &eacute; um
	    <literal>maintainer</literal> (mantenedor),
	    diga-o.</emphasis>  Se voc&ecirc; est&aacute; mantendo uma
	    parte do c&oacute;digo fonte (por exemplo, um port),
	    voc&ecirc; deve considerar a possibilidade de incluir as
	    palavras <literal>[maintainer update]</literal> (incluindo
	    os colchetes) no inicio da linha de sin&oacute;pse e 
	    deve definir a <quote><literal>class</literal></quote>
	    (classe) do seu PR para maintainer-update.  Desta forma 
	    qualquer <literal>committer</literal> que manusear o seu 
	    PR n&atilde;o ter&aacute; de verificar o
	    <filename>Makefile</filename> do port, para certificar-se
	    de que a atualiza&ccedil;&atilde;o foi enviada pelo
	    maintainer.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Seja espec&iacute;fico.</emphasis>  Quanto
	    mais informa&ccedil;&otilde;es voc&ecirc; fornecer sobre o
	    problema que voc&ecirc; est&aacute; tendo, melhores
	    ser&atilde;o as suas chances de obter uma resposta.</para>

	  <itemizedlist>
	    <listitem>
	      <para>Inclua a vers&atilde;o do &os; que voc&ecirc;
		est&aacute; utilizando (existe um lugar para colocar
		esta informa&ccedil;&atilde;o, veja abaixo) e em qual
		arquitetura.  Voc&ecirc; incluir a
		informa&ccedil;&atilde;o se est&aacute; executando a
		partir de um Release (e.g. de um CDROM ou Download),
		ou a partir de um sistema mantido com o &man.cvsup.1;
		(e neste caso, quando foi atualizado pela ultima
		vez).  Se voc&ecirc; estiver utilizando o
		&os.current;, esta vai ser a primeira coisa que
		algu&eacute;m ir&aacute; lhe perguntar, porque as
		corre&ccedil;&otilde;es (especialmente para os
		problemas de alto n&iacute;vel) tendem a serem
		realizadas muito rapidamente, e espera-se que os 
		usu&aacute;rios do &os.current; mantenham-se
		atualizados.</para>
	    </listitem>

	    <listitem>
	      <para>Inclua quais op&ccedil;&otilde;es globais
		voc&ecirc; especificou no seu
		<filename>make.conf</filename>.
		Observa&ccedil;&atilde;o:  &Eacute; conhecido que
		utilizar <literal>-O2</literal> (e acima disso) com o
		&man.gcc.1; gera problemas em muitas
		situa&ccedil;&otilde;es.  Apesar dos desenvolvedores
		do &os; aceitarem patches, eles normalmente n&atilde;o
		est&atilde;o dispostos a investigar este tipo de
		problema por uma simples falta de tempo e de
		volunt&aacute;rios, e ao inv&eacute;s disso podem
		responder apenas que isto n&atilde;o &eacute;
		suportado.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema pode ser reproduzido facilmente, 
		inclua informa&ccedil;&otilde;es para possibilitar 
		que ele seja reproduzido pelos desenvolvedores.  Se 
		o problema s&oacute; pode ser 
		demonstrado com a entrada de um conjunto de dados
		espec&iacute;fico, voc&ecirc; dever&aacute; incluir um
		exemplo destas informa&ccedil;&otilde;es, al&eacute;m
		de informar qual &eacute; resultado 
		atual (errado) e qual era o resultado esperado
		(correto).  Se o conjunto de dados for muito grande ou
		se o mesmo n&atilde;o puder ser tornado
		p&uacute;blico, tente criar um arquivo com o
		m&iacute;nimo 
		de informa&ccedil;&otilde;es necess&aacute;rias para
		replicar o problema, e que possa ser inclu&iacute;do
		no seu PR.</para>
	    </listitem>

	    <listitem>
	      <para>
		Se for um problema com o kernel, esteja preparado para
		fornecer as seguintes informa&ccedil;&otilde;es 
		(Voc&ecirc; n&atilde;o precisa fornecer estas
		informa&ccedil;&otilde;es por padr&atilde;o, o que
		s&oacute; tende a encher o banco de dados, mas
		voc&ecirc; deve incluir os trechos acreditar que 
		s&atilde;o relevantes):</para>
	      <itemizedlist>
		<listitem>
		  <para>A configura&ccedil;&atilde;o do seu kernel 
		    (incluindo quais dispositivos de hardware 
		    voc&ecirc; tem instalados)</para>
		</listitem>
		<listitem>
		  <para>Se voc&ecirc; tem ou n&atilde;o
		    op&ccedil;&otilde;es de depura&ccedil;&atilde;o
		    habilitadas (tais como 
		    <literal>WITNESS</literal>), e em caso afirmativo,
		    se o problema continua ocorrendo quando
		    voc&ecirc; altera a l&oacute;gica de
		    configura&ccedil;&atilde;o destas
		    op&ccedil;&otilde;es</para>
		</listitem>
		<listitem>
		  <para>O texto completo de qualquer
		    <literal>backtrace</literal>,
		    <literal>panic</literal> e outras
		    mensagens no console, ou os registros do
		    <filename>/var/log/messages</filename>, caso tenha
		    sido gerado algum</para>
		</listitem>
		<listitem>
		  <para>A sa&iacute;da do <command>pciconf
		    -l</command> e as partes relevantes da 
		    sa&iacute;da do <command>dmesg</command> se o
		    problema estiver relacionado a um componente de
		    hardware</para>
		</listitem>
		<listitem>
		  <para>O fato de que voc&ecirc; leu o 
		    <filename>src/UPDATING</filename> e que o seu 
		    problema n&atilde;o est&aacute; listado ali
		    (&eacute certeza que algu&eacute;m vai
		    perguntar)</para>
		</listitem>
		<listitem>
		  <para>Se voc&ecirc; consegue ou n&atilde;o executar 
		    outro kernel (Isto &eacute; para poder descartar a
		    possibilidade de ser um problema de hardware tais
		    como falha nos discos r&iacute;gidos e
		    superaquecimento dos processadores, cujos 
		    sintomas podem se confundir com problemas no 
		    kernel)</para>
		</listitem>
	      </itemizedlist>
	    </listitem>

	    <listitem>
	      <para>Se for um problema com um port, esteja preparado
		para fornecer as seguintes informa&ccedil;&otilde;es
		(Voc&ecirc; n&atilde;o precisa fornecer estas
		informa&ccedil;&otilde;es por padr&atilde;o, o que
		s&oacute; tende a encher o banco de dados, mas
		voc&ecirc; deve incluir os trechos acreditar que
		s&atilde;o relevantes):</para> 

	      <itemizedlist>
		<listitem>
		  <para>Quais ports voc&ecirc; tem instalados</para>
		</listitem>
		<listitem>
		  <para>As vari&aacute;veis de ambiente que substituem
		    os padr&otilde;es do
		    <filename>bsd.port.mk</filename>, como por exemplo
		    <makevar>PORTSDIR</makevar></para>
		</listitem>
		<listitem>
		  <para>O fato de que voc&ecirc; leu o
		    <filename>ports/UPDATING</filename> e que o seu
		    problema n&atilde;o est&aacute; listado ali
		    (&eacute certeza que algu&eacute;m vai
		    perguntar)</para>
		</listitem>
	      </itemizedlist>
	    </listitem>

	  </itemizedlist>

	</listitem>

	<listitem>
	  <para><emphasis>Evite pedidos vagos de novas
	    funcionalidades.</emphasis>  Os PRs no formato
	    <quote>algu&eacute;m realmente deveria implementar algo
	    que faz isso e aquilo</quote> s&atilde;o menos
	    prov&aacute;veis de obterem uma resposta do
	    que os que s&atilde;o mais espec&iacute;ficos.  Lembre-se,
	    o c&oacute;digo est&aacute; dispon&iacute;vel para todos,
	    de forma que se voc&ecirc; deseja uma nova funcionalidade,
	    a melhor maneira de ter certeza de que ela
	    ser&aacute; inclu&iacute;da &eacute; come&ccedil;ar a
	    trabalhar!  Tamb&eacute;m considere o fato de que
	    muitas destas sugest&otilde;es fariam mais sentido
	    como um t&oacute;pico de discuss&atilde;o na
	    <literal>freebsd-questions</literal> do que
	    como uma entrada no banco de dados de PRs, como
	    discutido acima.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Certifique-se de que ningu&eacute;m tenha
	    submetido um PR semelhante antes.</emphasis>  Embora isso
	    j&aacute; tenha sido mencionado anteriormente, faz sentido
	    repetir aqui.  Esta verifica&ccedil;&atilde;o ir&aacute;
	    lhe tomar apenas 1 ou 2 minutos no uso do <ulink
	    url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
	    mecanismo de busca</ulink> do banco de dados de PRs. 
	    (&eacute; claro, todos s&atilde;o culpados de j&aacute; 
	    terem esquecido de fazer isso de uma vez ou outra.)</para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Relate apenas um problema em cada
	      relat&oacute;rio.</emphasis>  Evite incluir dois ou mais
	      problemas em um mesmo relat&oacute;rio caso eles
	      n&atilde;o estejam relacionados.  Quando 
	      voc&ecirc; submeter um <literal>patch</literal>, evite
	      adicionar v&aacute;rias funcionalidades ou corrigir
	      v&aacute;rios bugs em um mesmo PR, a menos que eles 
	      sejam estritamente relacionados &mdash; Este tipo de 
	      PR muitas vezes demanda mais tempo para ser 
	      resolvido.</para>
	</listitem>

	<listitem>
	  <para> <emphasis>Evite solicita&ccedil;&otilde;es
	    pol&ecirc;micas.</emphasis>  Se o seu PR est&aacute;
	    relacionado a um tema que foi pol&ecirc;mico no passado,
	    voc&ecirc; deve estar preparado para n&atilde;o somente
	    disponibilizar um <literal>patch</literal>, como
	    tamb&eacute;m para defender porque o seu
	    <literal>patch</literal> &eacute <quote>a coisa certa a
	    se fazer</quote>.  Como mencionado acima, realizar uma
	    busca cuidadosa no hist&oacute;rico das <ulink
	    url="http://www.FreeBSD.org/search/search.html#mailinglists">listas
	    de discuss&atilde;o</ulink> &eacute; sempre uma boa 
	    forma de se preparar.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Seja educado.</emphasis>  Praticamente 
	    todas as pessoas que potencialmente podem trabalhar no 
	    seu PR s&atilde;o volunt&aacute;rios.  Ningu&eacute;m 
	    gosta de receber ordens para fazer algo que eles j&aacute;
	    est&atilde;o fazendo por alguma outra 
	    motiva&ccedil;&atilde;o a qual n&atilde;o &eacute; a de
	    ganho financeiro.  Esta &eacute; uma boa coisa para ter 
	    sempre em mente num projeto de c&oacute;digo 
	    aberto.</para>
	</listitem>
      </itemizedlist>
    </section>

    <section>
      <title>Antes de voc&ecirc; iniciar</title>

      <para>Antes de executar o programa &man.send-pr.1;,
	certifique-se que a sua vari&aacute;vel de ambiente
	<envar>VISUAL</envar> (ou a <envar>EDITOR</envar> se a
	<envar>VISUAL</envar> n&atilde;o estiver definida) 
	est&aacute; definida com seu editor preferido.</para>
      
      <para>Voc&ecirc; tamb&eacute;m deve certificar-se de que o seu 
	sistema de entrega de emails esta funcionando corretamente.  O
	&man.send-pr.1; utiliza mensagens de email para enviar e
	rastrear um relat&oacute;rio de problema.  Se voc&ecirc;
	n&atilde;o pode enviar mensagens de email a partir da
	m&aacute;quina na qual est&aacute; executando o
	&man.send-pr.1;, os seus relat&oacute;rios de problema
	n&atilde;o ir&atilde;o chegar at&eacute; a base de dados
	GNATS.  Para maiores detalhes de como configurar o sistema de
	email no &os;, consulte o cap&iacute;tulo sobre <quote>Correio
	Eletr&ocirc;nico</quote> no <ulink
	url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html">Handbook
	do FreeBSD</ulink>.</para>
      
      <para>Certifique-se de que o seu sistema de email n&atilde;o
	ir&aacute; alterar a formata&ccedil;&atilde;o da mensagem ao
	encaminh&aacute;-la para o GNATS.  Qualquer
	<literal>patch</literal> que voc&ecirc; enviar ser&aacute;
	inutilizado, caso o seu sistema de email quebre
	automaticamente as linhas, troque
	tabula&ccedil;&otilde;es por espa&ccedil;os em branco ou
	altere os caracteres de mudan&ccedil;a para uma nova linha,
	etc.  Entretanto, para as se&ccedil;&otilde;es de texto
	n&oacute;s pedimos que voc&ecirc; quebre manualmente as linhas
	pr&oacute;ximo dos 70 caracteres, desta forma a vers&atilde;o
	web do PR poder&aacute; ser lida melhor.</para>
  	
      <para>Considera&ccedil;&otilde;es similares se aplicam se
	voc&ecirc; estiver utilizando o <ulink
	url="&url.base;/send-pr.html">formul&aacute;rio web de
	submiss&atilde;o de PR</ulink> ao inv&eacute;s de utilizar o
	&man.send-pr.1;.  Observe que opera&ccedil;&otilde;es de
	copiar-e-colar possuem seus pr&oacute;prios efeitos colaterais
	na formata&ccedil;&atilde;o do texto.  Em certos casos, pode
	ser necess&aacute;rio usar o &man.uuencode.1; para garantir
	que os patches cheguem sem modifica&ccedil;&otilde;es.</para>

      <para>Finalmente, se a sua submiss&atilde;o ser&aacute; longa,
	voc&ecirc; deve preparar o texto do seu 
	relat&oacute;rio offline, desta forma nada ser&aacute; 
	perdido no caso de voc&ecirc; ter problemas quando for 
	submet&ecirc;-lo.  Isto pode ser um problema, em especial, 
	se voc&ecirc; estiver utilizando o <ulink
	url="&url.base;/send-pr.html">formul&aacute;rio
	web</ulink>.</para>
    </section>

    <section>
      <title>Anexando <literal>patches</literal> ou arquivos</title>

      <para>As instru&ccedil;&otilde;es abaixo se aplicam ao envio 
	de PRs por email:</para>

      <para>O programa &man.send-pr.1; tem a capacidade de anexar 
	arquivos em um relat&oacute;rio de problemas.  Voc&ecirc; 
	pode anexar quantos arquivos desejar desde que os mesmos 
	possuam nomes &uacute;nicos (i.e. o nome pr&oacute;prio do 
	arquivo, sem o caminho de diret&oacute;rio).  Basta usar a
	op&ccedil;&atilde;o <option>-a</option> na linha de comando
	para anexar os arquivos desejados:</para>

<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>

      <para>N&atilde;o se preocupe com os arquivos bin&aacute;rios,
	eles ser&atilde;o encodados automaticamente de forma a
	n&atilde;o perturbar o seu agente de correio.</para>

      <para>Se voc&ecirc; anexar um <literal>patch</literal>, tenha
	certeza de utilizar a op&ccedil;&atilde;o <option>-c</option>
	ou <option>-u</option> no &man.diff.1; para criar um diff
	contextual ou um diff unificado (o formato unificado &eacute;
	preferido), e tenha certeza de especificar os n&uacute;meros
	de revis&atilde;o exatos dos arquivos que voc&ecirc;
	modificou, desta forma o desenvolvedor que ler seu
	relat&oacute;rio ter&aacute; condi&ccedil;&otilde;es de
	aplic&aacute;-los facilmente.  Para problemas com o kernel ou
	com os aplicativos do sistema base, um
	<literal>patch</literal> para o &os.current; (o ramo HEAD do
	CVS) &eacute; preferido uma vez que todo novo c&oacute;digo
	deve ser aplicado e testado primeiro nele.  Depois que forem
	realizados os testes apropriados, o c&oacute;digo ser&aacute;
	fundido ou migrado para o ramo &os.stable;.</para>
      
      <para>Se voc&ecirc; juntar um <literal>patch</literal>
	no corpo do email, em vez de envi&aacute;-lo como um
	arquivo anexo, voc&ecirc; estar&aacute; sujeito a
	ocorr&ecirc;ncia de um problema bastante comum ocasionado
	pela tend&ecirc;ncia de alguns clientes de email de converter
	tabs em espa&ccedil;os, o que ir&aacute; arruinar
	completamente qualquer coisa que voc&ecirc; tenha enviado
	com inten&ccedil;&atilde;o de que fosse parte de um
	Makefile.</para>

      <para>N&atilde;o envie <literal>patches</literal> como anexos 
	usando <command>Content-Transfer-Encoding: quoted-printable
	</command>.  Isto ir&aacute; realizar 
	<literal>character escaping</literal> e o 
	<literal>patch</literal> inteiro estar&aacute;
	inutilizado.</para>
      
      <para>Observe tamb&eacute;m que incluir pequenos
	<literal>patches</literal> em um PR &eacute; normalmente a
	coisa certa a se fazer &mdash; particularmente quando ele
	corrige o problema descrito no PR &mdash; grandes
	<literal>patches</literal> e especialmente c&oacute;digo novo,
	que normalmente requerem uma revis&atilde;o substancial antes
	de serem incorporados, devem ser colocados em um servidor web
	ou de FTP, e a url deve ser inclu&iacute;da no PR ao
	inv&eacute;s do <literal>patch</literal> propriamente dito.
	Os <literal>patches</literal> dentro de um email tendem a se
	deformar, especialmente quando o GNATS est&aacute; envolvido,
	e quanto maior o patch, maior &eacute; a dificuldade para 
	ambas as partes em consert&aacute;-lo.  Al&eacute;m de que, ao
	colocar o <literal>patch</literal> na web, voc&ecirc; pode
	modific&aacute;-lo sem ter que reenviar o arquivo completo
	como um <literal>followup</literal> do PR original.
	Al&eacute;m disso, os grandes <literal>patches</literal>
	simplesmente aumentam o tamanho do banco de dados, uma vez que
	os relat&oacute;rios de problema fechados n&atilde;o
	s&atilde;o deletados, continuando a existir marcados como
	<literal>closed</literal>.</para>
      
      <para>Voc&ecirc; deve observar que a menos que 
	especifique explicitamente no seu PR ou diretamente no seu 
	patch, qualquer corre&ccedil;&atilde;o que voc&ecirc; envie
	ser&aacute; considerada como estando licenciada sob os mesmos
	termos do arquivo original que voc&ecirc; modificou.</para>
    </section>

    <section>
      <title>Preenchendo o template</title>

      <para>As instru&ccedil;&otilde;es abaixo se aplicam apenas ao
	envio de PRs por email:</para>

      <para>Quando voc&ecirc; executar o programa &man.send-pr.1;,
	voc&ecirc; ser&aacute; apresentado a um template.  O template
	consiste em uma lista de campos, alguns dos quais
	estar&atilde;o pr&eacute;-preenchidos, e alguns ir&atilde;o
	possuir coment&aacute;rios explicando o seu prop&oacute;sito
	ou ent&atilde;o listando os valores aceit&aacute;veis.
	N&atilde;o se preocupe com os coment&aacute;rios, eles
	ser&atilde;o removidos automaticamente se voc&ecirc;
	n&atilde;o modific&aacute;-los ou ent&atilde;o os remova
	voc&ecirc; mesmo.</para>
      
      <para>Na parte superior do template, logo abaixo das linhas
	<literal>SEND-PR:</literal>, est&aacute; o cabe&ccedil;alho do
	email.  Voc&ecirc; normalmente n&atilde;o necessita
	modific&aacute;-lo, a menos que voc&ecirc; esteja enviando o
	relat&oacute;rio de problema a partir de uma m&aacute;quina ou
	de uma conta a qual pode enviar, mas n&atilde;o pode receber
	emails, neste caso voc&ecirc; deve configurar manualmente os
	campos <literal>From:</literal> e <literal>Reply-To:</literal>
	para o seu endere&ccedil;o de email real.  Voc&ecirc;
	tamb&eacute;m pode querer enviar uma c&oacute;pia do
	relat&oacute;rio para voc&ecirc; mesmo (ou para alguma outra
	pessoa) atrav&eacute;s do uso de uma c&oacute;pia carbono,
	adicionando um ou mais endere&ccedil;os de email na linha de
	cabe&ccedil;alho <literal>Cc:</literal>.</para>
      
      <para>Os campos de linha &uacute;nica descritos abaixo,
	est&atilde;o dispon&iacute;veis apenas no template do
	email:</para>
      
      <itemizedlist>
	<listitem>
	  <para><emphasis>Submitter-Id:</emphasis> N&atilde;o altere
	    este campo.  O valor padr&atilde;o  &eacute;
	    <literal>current-users</literal> e est&aacute; correto,
	    mesmo se voc&ecirc; estiver executando o 
	    &os.stable;.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Confidential:</emphasis> N&atilde;o altere
	    este campo.  O valor padr&atilde;o &eacute; 
	    <literal>no</literal>.  N&atilde;o tem sentido
	    alter&aacute;-lo j&aacute; que n&atilde;o existem
	    relat&oacute;rios de problema confidenciais no &os;
	    &mdash; o banco de dados de PR &eacute;
	    distribu&iacute;do mundialmente pelo
	    <application>CVSup</application>.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Severity:</emphasis>  Escolha uma
	    op&ccedil;&atilde;o entre <literal>non-critical</literal>,
	    <literal>serious</literal> ou <literal>critical</literal>.
	    N&atilde;o fa&ccedil;a esc&acirc;ndalo; abstenha-se de
	    rotular seu problema como <literal>critical</literal> a
	    menos que ele realmente seja (por ex. quest&otilde;es de
	    corrup&ccedil;&atilde;o de dados, grave retrocesso de
	    funcionalidade no -CURRENT em rela&ccedil;&atilde;o a
	    vers&atilde;o anterior, etc)ou de
	    <literal>serious</literal> a menos que seja algo que vai
	    afetar muitos usu&aacute;rios (Kernel panic ou travamentos
	    do sistema; Problemas com algum driver de dispositivo em
	    particular ou com utilit&aacute;rios de sistema).  Os
	    desenvolvedores do &os; n&atilde;o ir&atilde;o
	    necessariamente trabalhar no seu problema mais
	    r&aacute;pido se voc&ecirc; inflar sua import&acirc;ncia
	    uma vez que existem muitas outras pessoas que fizeram
	    exatamente isso &mdash; na verdade, alguns desenvolvedores
	    prestam pouca aten&ccedil;&atilde;o a este campo por causa
	    disso.</para>

	    <note>
	      <para>Problemas de seguran&ccedil;a 
		<emphasis>n&atilde;o</emphasis> devem ser submetidos
		para o GNATS, pois todas as informa&ccedil;&otilde;es
		no GNATS s&atilde;o de conhecimento p&uacute;blico.
		Por favor, envie estes problemas seguindo as nossas 
		<ulink url="http://security.freebsd.org/#how">diretrizes 
		sobre relat&oacute;rios de seguran&ccedil;a</ulink>.
		</para>
		
		
	    </note>
	  </listitem>

	  <listitem>
	    <para><emphasis>Priority:</emphasis> Escolha uma
	      op&ccedil;&atilde;o entre <literal>low</literal>,
	      <literal>medium</literal> ou <literal>high</literal>.
	      <literal>high</literal> deve ser reservada para os
	      problemas que afetam praticamente todos os
	      usu&aacute;rios do &os; e <literal>medium</literal> para
	      os problemas que v&atilde;o afetar muitos
	      usu&aacute;rios.</para>

	    <note>
	      <para>Este campo tornou-se t&atilde;o amplamente abusado que
		perdeu quase que completamente seu objetivo.</para>
	    </note>
	  </listitem>
      </itemizedlist>

      <para>A pr&oacute;xima se&ccedil;&atilde;o descreve os campos 
	que s&atilde;o comuns entre a interface por email e a
	<ulink url="&url.base;/send-pr.html">interface web</ulink>:</para>

      <itemizedlist>

	<listitem>
	  <para><emphasis>Originator:</emphasis>
	    Por favor informe seu nome completo, seguido opcionalmente
	    pelo seu endere&ccedil;o de email entre colchetes.
	    Na interface de email, este campo &eacute; normalmente 
	    pr&eacute;-preenchido com o campo
	    <literal>gecos</literal> do usu&aacute;rio com o qual
	    voc&ecirc; est&aacute; atualmente logado.</para>

	  <note>
	    <para>O endere&ccedil;o de email que voc&ecirc; utilizar
	      ir&aacute; se tornar uma informa&ccedil;&atilde;o
	      p&uacute;blica e pode vir a se tornar dispon&iacute;vel
	      para spammers.  Voc&ecirc; dever&aacute; ter um sistema
	      antispam funcional ou ent&atilde;o dever&aacute;
	      utilizar uma conta tempor&aacute;ria de email.
	      Contudo, por favor, lembre-se que se voc&ecirc;
	      n&atilde;o utilizar uma conta de email v&aacute;lida,
	      n&oacute;s n&atilde;o seremos capazes de entrar em
	      contato com voc&ecirc; para fazer perguntas sobre o
	      seu PR.</para>
	  </note>

	</listitem>

	<listitem>
	  <para><emphasis>Organization:</emphasis> Campo livre para 
	    o que voc&ecirc; quiser colocar.  Este campo n&atilde;o
	    &eacute; utilizado para nada significativo.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Synopsis:</emphasis> Preencha este campo com
	    uma descri&ccedil;&atilde;o curta e precisa sobre o seu
	    problema.  A <literal>synopsis</literal> &eacute;
	    utilizada como o assunto do email do relat&oacute;rio de
	    problema, e tamb&eacute;m &eacute; utilizada na listagem 
	    de relat&oacute;rio de problemas e resumos;
	    relat&oacute;rios de problema com 
	    <literal>synopses</literal> obscuras tendem a serem 
	    ignorados.</para>
	  
	  <para>Como mencionado acima, se o seu relat&oacute;rio de
	    problema inclui um <literal>patch</literal>, por favor,
	    inicie sua <literal>synopsis</literal> com
	    <literal>[patch]</literal> (incluindo os colchetes); se
	    voc&ecirc; for um <literal>maintainer</literal> considere
	    adicionar <literal>[maintainer update]</literal>
	    (incluindo os colchetes) ao in&iacute;cio da sua
	    <literal>synopsis</literal> e defina a
	    <quote>classe</quote> do seu PR para
	    <literal>maintainer-update</literal>.</para> 
	</listitem>

	<listitem>
	  <para><emphasis>Category:</emphasis> Escolha uma categoria
	    adequada.</para>

	  <para>
	    A primeira coisa que voc&ecirc; precisa fazer &eacute;
	    decidir em qual parte do sistema o seu problema
	    est&aacute;.  Lembre-se, o &os; &eacute; um sistema
	    operacional completo, o qual instala um kernel, as
	    bibliotecas padr&atilde;o, muitos
	    <literal>drivers</literal> de dispositivos e um grande
	    n&uacute;mero de utilit&aacute;rios (este conjunto
	    recebe o nome de <quote>sistema base</quote>).  No
	    entanto, existem milhares de aplicativos adicionais na
	    Cole&ccedil;&atilde;o de Ports.  Voc&ecirc; primeiro
	    precisa decidir se o problema est&aacute; no sistema base
	    ou se est&aacute; em algo que foi instalado atrav&eacute;s
	    da Cole&ccedil;&atilde;o de Ports.</para>
	  
	  <para>Aqui est&aacute; uma descri&ccedil;&atilde;o das
	    principais categorias:</para>

	  <itemizedlist>
	    <listitem>
	      <para>
		Se o problema &eacute; com o Kernel, com as
		bibliotecas (tal como a biblioteca C padr&atilde;o,
		libc), ou com um <literal>driver</literal> de
		dispositivo do sistema base, em geral voc&ecirc; vai
		usar a categoria kern.  (Existem algumas
		exce&ccedil;&otilde;es; veja abaixo).  Em geral, estas
		s&atilde;o coisas que est&atilde;o descritas nas
		se&ccedil;&otilde;es 2, 3 ou 4 das p&aacute;ginas de
		manual.</para>
	    </listitem>

	    <listitem>
	      <para> 
		Se o problema &eacute; com um programa bin&aacute;rio,
		tal como o &man.sh.1; ou o &man.mount.8;, primeiro
		voc&ecirc; precisa determinar se estes programas
		pertencem ao sistema base ou se foram adicionados
		atrav&eacute;s da cole&ccedil;&atilde;o de ports.  Se
		voc&ecirc; estiver na d&uacute;vida, voc&ecirc; pode 
		executar um <command>whereis <replaceable>
		nomedoprograma</replaceable></command>, no
		&os; por conven&ccedil;&atilde;o todos os aplicativos
		da cole&ccedil;&atilde;o de ports s&atilde;o
		instalados sob <filename
		class="directory">/usr/local</filename>, embora isso
		possa ser alterado por um administrador de sistemas.
		Para estes, voc&ecirc; ir&aacute; utilizar a categoria
		<literal>ports</literal> (sim, mesmo que a categoria
		do port seja <literal>www</literal>; veja abaixo).  Se
		a localiza&ccedil;&atilde;o do aplicativo for 
		<filename class="directory">/bin</filename>, <filename
		class="directory">/usr/bin</filename>, <filename
		class="directory">/sbin</filename>, ou <filename
		class="directory">/usr/sbin</filename>, ele
		faz parte do sistema base, e voc&ecirc;
		dever&aacute; utilizar a categoria
		<literal>bin</literal>.  (Alguns programas, como o
		&man.gcc.1;, na pr&aacute;tica utilizam a categoria
		<literal>gnu</literal>, mas n&atilde;o se preocupe
		com isso por agora.)  Todos estes aplicativos
		est&atilde;o descritos nas se&ccedil;&otilde;es 1 ou 8
		das p&aacute;ginas de manual.</para>
	    </listitem>

	    <listitem>
	      <para>Se voc&ecirc; acredita que o erro est&aacute; no
		script de inicializa&ccedil;&atilde;o 
		<literal>(rc)</literal>, ou em algum outro tipo de
		arquivo de configura&ccedil;&atilde;o n&atilde;o
		execut&aacute;vel, ent&atilde;o a categoria indicada
		ser&aacute; a <literal>conf</literal>
		(configura&ccedil;&atilde;o).  Estas s&atilde;o coisas
		descritas na se&ccedil;&atilde;o 5 das p&aacute;ginas
		de manual.</para>
	    </listitem>

	    <listitem>
	      <para>Se voc&ecirc; encontrou um problema na 
		documenta&ccedil;&atilde;o (artigos, livros, 
		p&aacute;ginas de manual, etc.), a escolha 
		correta para a categoria &eacute; a
		op&ccedil;&atilde;o <literal>docs</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se voc&ecirc; est&aacute; tendo problemas com as
	      <ulink url="http://www.FreeBSD.org">p&aacute;ginas web 
	      do &os;</ulink>, a escolha apropriada &eacute; 
	      <literal>www</literal>.</para>

	      <note>
		<para>Independentemente se voc&ecirc; est&aacute; 
		  tendo algum problema com um port chamado 
		  <literal>www/<replaceable>nomedoport</replaceable></literal>,
		  a categoria correta para o mesmo ser&aacute;
		  <literal>ports</literal>.</para>
	      </note>
	    </listitem>
	  </itemizedlist>

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

	  <itemizedlist>
	    <listitem>
	      <para>Se o problema pode ser classificado na 
	     	categoria <literal>kern</literal>, e est&aacute;
		relacionado ao subsistema USB, a categoria correta
	      	ser&aacute; <literal>usb</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema pode ser classificado na categoria
		<literal>kern</literal>, e est&aacute; relacionado com 
		as bibliotecas de threads, a categoria correta
		ser&aacute; <literal>threads</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>Se o problema est&aacute; localizado no sistema
		base, mas est&aacute; relacionado a nossa
		ader&ecirc;ncia a padr&otilde;es tais como o 
		&posix;, a categoria correta ser&aacute;
	      <literal>standards</literal>.</para>
	    </listitem>

	    <listitem>
	      <para>
		Se o problema est&aacute; relacionado a erros internos
		de uma &java.virtual.machine; (&jvm;), mesmo que o
		&java; tenha sido instalado a partir da
		cole&ccedil;&atilde;o de ports, voc&ecirc; deve
		selecionar a categoria <literal>java</literal>.
		Problemas gen&eacute;ricos com o port do &java; devem
		continuar sendo enviados na categoria
		<literal>ports</literal>.</para>
	    </listitem>
	  </itemizedlist>

	  <para>Isto deixa tudo mais.</para>
	  
	  <itemizedlist>
	    <listitem>
	      <para>Se voc&ecirc; est&aacute; convencido de que o
		problema ir&aacute; ocorrer apenas na arquitetura do
		processador que voc&ecirc; est&aacute; utilizando,
		selecione uma categoria espec&iacute;fica para a sua
		arquitetura: geralmente <literal>i386</literal> para
		m&aacute;quinas compat&iacute;veis com a arquitetura
		Intel de 32 bits, <literal>amd64</literal> para
		m&aacute;quinas AMD executando em modo 64 bits (o que
		tamb&eacute;m inclui m&aacute;quinas
		compat&iacute;veis com a arquitetura Intel executando
		em modo EMT64); e menos comumente
		<literal>ia64</literal>, <literal>powerpc</literal>, e
		<literal>sparc64</literal>.</para>

	      <note>
		<para>Estas categorias s&atilde;o muitas vezes
		  utilizadas de forma indevida para problemas do
		  tipo <quote>Eu n&atilde;o sei</quote>.  Em vez de
		  tentar adivinhar, por favor, apenas utilize a
		  categoria <literal>misc</literal>.</para>
	      </note>

	      <example>
		<title>Uso correto da categoria espec&iacute;fica de
		  arquitetura.</title>

		<para>Voc&ecirc; tem um computador comum (PC), e 
		  acredita que encontrou um problema espec&iacute;fico
		  com um chipset em particular ou com uma placa
		  m&atilde;e espec&iacute;fica: A categoria correta
		  &eacute; <literal>i386</literal>.</para>
	      </example>

	      <example>
		<title>Uso incorreto da categoria espec&iacute;fica de 
		  arquitetura.</title>

		<para>Voc&ecirc; est&aacute; tendo problemas com uma
		  placa de expans&atilde;o instalada em um barramento
		  bastante comum, ou um problema com um tipo
		  espec&iacute;fico de disco r&iacute;gido: neste 
		  caso, &eacute; prov&aacute;vel que o problema 
		  ocorra em mais de uma arquitetura, e a categoria
		  correta seria <literal>kern</literal>.</para>
	      </example>
	    </listitem>

	    <listitem>
	      <para>Se voc&ecirc; realmente n&atilde;o sabe onde
		est&aacute; o problema (ou o mesmo n&atilde;o parece
		se encaixar nas categorias acima), utilize a categoria
		<literal>misc</literal>.  Mas antes de fazer isto,
		pode ser uma boa id&eacute;ia primeiro pedir ajuda na
		&a.questions;.  Voc&ecirc; poder&aacute; ser orientado 
		&agrave; utilizar uma das outras categorias para 
		obter um melhor resultado.</para>
	    </listitem>
	  </itemizedlist>

	  <para>Aqui est&aacute; a lista atual de categorias
	    (retirada do url <ulink 
	    url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories"></ulink>):</para>

	  <itemizedlist>
	    <listitem>
	      <para><literal>advocacy:</literal> problemas
		relacionados a imagem p&uacute;blica do &os;.
		Obsoleta.</para>
	    </listitem>

	    <listitem>
	      <para><literal>alpha:</literal> problemas 
		espec&iacute;ficos da plataforma Alpha.</para>
	    </listitem>

	    <listitem>
	      <para><literal>amd64:</literal> problemas 
		espec&iacute;ficos da plataforma AMD64.</para>
	    </listitem>

	    <listitem>
	      <para><literal>arm:</literal> problemas 
		espec&iacute;ficos da plataforma ARM.</para>
	    </listitem>

	    <listitem>
	      <para><literal>bin:</literal> problemas com os programas
		de n&iacute;vel de usu&aacute;rio na base do
		sistema.</para>
	    </listitem>

	    <listitem>
	      <para><literal>conf:</literal> problemas com os arquivos
		de configura&ccedil;&atilde;o, valores padr&otilde;es,
		etc.</para>
	    </listitem>

	    <listitem>
	      <para><literal>docs:</literal> problemas com as
		p&aacute;ginas de manuais ou com a
		documenta&ccedil;&atilde;o online.</para>
	    </listitem>

	    <listitem>
	      <para><literal>gnu:</literal> problemas com softwares 
		GNU, tais como &man.gcc.1; ou &man.grep.1;.</para>
	    </listitem>

	    <listitem>
	      <para><literal>i386:</literal> problemas 
		espec&iacute;ficos da plataforma &i386;.</para>
	    </listitem>

	    <listitem>
	      <para><literal>ia64:</literal> problemas 
	      espec&iacute;ficos da plataforma ia64.</para>
	    </listitem>

	    <listitem>
	      <para><literal>java:</literal> problemas relacionados
		com a Maquina Virtual &java;.</para>
	    </listitem>

	    <listitem>
	      <para><literal>kern:</literal> problemas com o kernel,
		drivers de dispositivo (n&atilde;o espec&iacute;ficos
		&agrave; uma plataforma), ou bibliotecas do sistema
		base.</para>
	    </listitem>

	    <listitem>
	      <para><literal>misc:</literal> Tudo aquilo que
		n&atilde;o se encaixa numa das outras
		categorias.  (observe que n&atilde;o existe nada que
		perten&ccedil;a verdadeiramente a esta categoria,
		exceto os problemas com a infra estrutura de build e
		de release.  As falhas tempor&aacute;rias de
		compila&ccedil;&atilde;o do <literal>HEAD</literal>
		n&atilde;o pertencem a esta categoria.  Tamb&eacute;m
		observe que &eacute; f&aacute;cil para as coisas se
		perderem nesta categoria).</para>
	    </listitem>

	    <listitem>
	      <para><literal>ports:</literal> problemas relacionados
		com a Cole&ccedil;&atilde;o de Ports.</para>
	    </listitem>

	    <listitem>
	      <para><literal>powerpc:</literal> problemas 
		espec&iacute;ficos da plataforma &powerpc;.</para>
	    </listitem>

	    <listitem>
	      <para><literal>sparc64:</literal> problemas
		espec&iacute;ficos da plataforma &sparc64;.</para>
	    </listitem>

	    <listitem>
	      <para><literal>standards:</literal> problemas 
		relacionados a conformidade com os
		padr&otilde;es.</para>
	     </listitem>

	    <listitem>
	      <para><literal>threads:</literal> problemas relacionados
	      	a implementa&ccedil;&atilde;o de threads no &os;
		(especialmente no &os.current;).</para> 
	     </listitem>

	    <listitem>
	      <para><literal>usb:</literal> problemas relacionados a
		implementa&ccedil;&atilde;o do USB no &os;.</para>
	     </listitem>

	     <listitem>
	       <para><literal>www:</literal> mudan&ccedil;as e
		melhorias no web site do &os;.</para>
	     </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Class:</emphasis> Escolha uma das seguintes
	    op&ccedil;&otilde;es:</para>

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

	    <listitem>
	      <para><literal>doc-bug:</literal> erros na
		documenta&ccedil;&atilde;o.</para>
	    </listitem>

	    <listitem>
	      <para><literal>change-request:</literal>
		solicita&ccedil;&atilde;o de novas funcionalidades 
		ou de altera&ccedil;&otilde;es em funcionalidades 
		existentes.</para>
	    </listitem>

	    <listitem>
	      <para><literal>update:</literal>
	      	atualiza&ccedil;&otilde;es para o ports ou para
		outros softwares de terceiros.</para>
	    </listitem>

	    <listitem>
	      <para><literal>maintainer-update:</literal> 
		atualiza&ccedil;&otilde;es de ports pelos quais
		voc&ecirc; &eacute; o respons&aacute;vel.</para>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Release:</emphasis> &Eacute; a vers&atilde;o
	    do &os; que voc&ecirc; est&aacute; utilizando.  Este campo
	    &eacute; preenchido automaticamente pelo &man.send-pr.1; e
	    s&oacute; necessita ser alterado se voc&ecirc; estiver
	    enviando o relat&oacute;rio de problema de um sistema
	    diferente do que apresenta o problema.</para>
	</listitem>
      </itemizedlist>

      <para>Finalmente, h&aacute; uma s&eacute;rie de campos de
	v&aacute;rias linhas:</para> 

      <itemizedlist>
	<listitem>
	  <para><emphasis>Environment:</emphasis> Este campo 
	    deve descrever, da forma mais precisa
	    poss&iacute;vel, o ambiente no qual o problema foi
	    observado.  Isto inclui a vers&atilde;o do sistema
	    operacional, a vers&atilde;o do programa ou do arquivo
	    espec&iacute;fico que cont&eacute;m o problema, e qualquer
	    outro item relevante tal como a configura&ccedil;&atilde;o
	    do sistema, outros softwares instalados que tenham
	    influ&ecirc;ncia no problema, etc. &mdash; ou seja, 
	    simplesmente tudo o que um desenvolvedor precisar saber 
	    para reconstruir o ambiente no qual o problema 
	    ocorreu.</para>
	</listitem>

	<listitem>
	  <para><emphasis>Description:</emphasis> Uma 
	    descri&ccedil;&atilde;o precisa e completa do problema
	    que voc&ecirc; esta experimentando.  Tente evitar
	    especular sobre as causas do problema a menos que
	    voc&ecirc; tenha certeza de que est&aacute; no caminho
	    certo, do contr&aacute;rio voc&ecirc; pode induzir o
	    desenvolvedor a fazer suposi&ccedil;&otilde;es incorretas
	    sobre o problema.</para>
	</listitem>

	<listitem>
	  <para><emphasis>How-To-Repeat:</emphasis> Um resumo com as 
	    a&ccedil;&otilde;es que voc&ecirc; precisa executar para
	    reproduzir o problema.</para>
	    
	</listitem>

	<listitem>
	  <para><emphasis>Fix:</emphasis> Preferencialmente um 
	    <literal>patch</literal>, ou no
	    m&iacute;nimo um <literal>workaround</literal> (o que
	    n&atilde;o s&oacute; ajuda as outras pessoas que
	    est&atilde;o com o mesmo problema, como tamb&eacute;m
	    auxilia o desenvolvedor a entender melhor a causa do
	    problema), mas se voc&ecirc; n&atilde;o tem nenhuma
	    id&eacute;ia consistente, &eacute; melhor deixar este
	    campo em branco do que especular.</para>
	</listitem>
      </itemizedlist>
    </section>

    <section>
      <title>Enviando o relat&oacute;rio de problemas</title>
      
      <para>Se voc&ecirc; est&aacute; utilizando o
	&man.send-pr.1;:</para>

      <para>Uma vez que voc&ecirc; tenha terminado de preencher o
	template, salve-o, e saia do editor de texto, ao fazer isto o
	&man.send-pr.1; ir&aacute; lhe perguntar se voc&ecirc; deseja
	<prompt>s)end, e)dit or a)bort?</prompt>.  Para ir em frente e
	enviar o relat&oacute;rio de problema pressione
	<userinput>s</userinput>, caso voc&ecirc; queira voltar ao
	editor para realizar alguma altera&ccedil;&atilde;o pressione
	<userinput>e</userinput>, ou ent&atilde;o pressione
	<userinput>a</userinput> para cancelar o envio.  Se voc&ecirc;
	optar por abortar, o seu relat&oacute;rio de problema
	ir&aacute; permanecer no seu disco r&iacute;gido (o
	&man.send-pr.1; ir&aacute; lhe informar o nome do arquivo
	antes de finalizar), assim voc&ecirc; poder&aacute;
	edit&aacute;-lo quando for mais conveniente, ou poder&aacute;
	transferi-lo para um sistema com uma melhor
	conectividade, no qual poder&aacute; envi&aacute;-lo usando a
	op&ccedil;&atilde;o <option>-f</option> com o
	&man.send-pr.1;:</para>

<screen>&prompt.user; <userinput>send-pr -f ~/my-problem-report</userinput></screen>

      <para>Este comando ir&aacute; ler o arquivo especificado, 
	validar o seu conte&uacute;do, remover os coment&aacute;rios 
	e enviar o seu PR.</para>
      
      <para>Se voc&ecirc; est&aacute; utilizando o <ulink 
	url="&url.base;/send-pr.html">formul&aacute;rio
	web</ulink>:</para>

      <para>Antes de pressionar o bot&atilde;o
     	<literal>submit</literal> para enviar o seu relat&oacute;rio,
	voc&ecirc; ter&aacute que preencher um campo com o texto 
	exibido na imagem de captcha exibida no final do 
	formul&aacute;rio.  Infelizmente esta medida teve de ser 
	adotada devido ao mau uso do mesmo por sistemas automatizados 
	e por alguns indiv&iacute;duos mal intencionados.  &Eacute; um
	mal necess&aacute;rio do qual ningu&eacute;m gosta.
	Por favor, n&atilde;o pe&ccedil;a para
	remov&ecirc;-lo.</para>
      
      <para>
	Recomendamos <emphasis>fortemente</emphasis> que voc&ecirc; 
	salve o seu trabalho em algum outro lugar antes de 
	pressionar o bot&atilde;o <literal>submit</literal>.  Um 
	problema comum e que ocorre com muitos usu&aacute;rios 
	&eacute; a visualiza&ccedil;&atilde;o de uma imagem de 
	captcha velha exibida a partir do cache do navegador.  Se 
	isso acontecer com voc&ecirc; o seu envio ser&aacute; 
	rejeitado e voc&ecirc; poder&aacute; perder o seu 
	trabalho.</para>
      
      <para>Se voc&ecirc;, por qualquer motivo, n&atilde;o conseguir
	visualizar as imagens, e tamb&eacute;m estiver impossibilitado
	de utilizar o &man.send-pr.1;, por favor, aceite nossas 
	desculpas por est&aacute; inconveni&ecirc;ncia e envie seu 
	relat&oacute;rio de problema por e-mail para a equipe de 
	bugbusters do &os;, no endere&ccedil;o
	<email>freebsd-bugbusters@FreeBSD.org</email>.</para>
    </section>

  </section>

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

    <para>
      Depois que seu relat&oacute;rio de problema tiver sido entregue,
      voc&ecirc; receber&aacute; uma confirma&ccedil;&atilde;o por
      e-mail com o n&uacute;mero de rastreamento que foi
      atribu&iacute;do ao mesmo e uma URL a
      qual voc&ecirc; poder&aacute; utilizar para consultar o status
      do seu PR.  Com um pouco de sorte, algu&eacute;m ir&aacute; se
      interessar pelo seu problema e tentar&aacute; resolv&ecirc;-lo,
      ou, conforme o caso explicar porque n&atilde;o se trata de um
      problema.  Voc&ecirc; ser&aacute; notificado automaticamente de
      qualquer mudan&ccedil;a de status, e ir&aacute;
      receber uma c&oacute;pia de qualquer coment&aacute;rio ou
      corre&ccedil;&atilde;o que algu&eacute;m venha a anexar &agrave;
      trilha de auditoria do seu relat&oacute;rio de problema.</para>
    
    <para>Se algu&eacute;m lhe requisitar alguma 
      informa&ccedil;&atilde;o adicional, ou se voc&ecirc; 
      lembrar de algo ou descobrir algo que voc&ecirc; n&atilde;o 
      tenha mencionado no seu relat&oacute;rio inicial, por favor 
      utilize um dos dois m&eacute;todos abaixo para enviar uma 
      atualiza&ccedil;&atilde;o:</para>

    <itemizedlist>
      <listitem>
	<para>A forma mais f&aacute;cil &eacute; utilizar o link e
	  <literal>followup</literal> existente na p&aacute;gina web
	  individual de cada PR, a qual pode ser encontrada a partir
	  da <ulink
	  url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
	  p&aacute;gina de busca de relat&oacute;rios</ulink>.  Ao
	  clicar no link ser&aacute; aberta uma janela do seu
	  cliente de e-mail com os campos <literal>To:</literal> e
	  <literal>Subject:</literal> j&aacute; corretamente 
	  preenchidos (se o seu navegador estiver configurado
	  corretamente para fazer isto).</para>
      </listitem>

      <listitem>
	<para>Alternativamente, voc&ecirc; pode apenas envi&aacute;-lo
	  para &a.bugfollowup;, certificando-se de que o n&uacute;mero
	  de rastreamento est&aacute; incluso no
	  <literal>Subject:</literal> de forma que o sistema de
	  acompanhamento de bugs tenha como saber em qual
	  relat&oacute;rio de problema ele deve anexar o material
	  recebido.</para>

	<note>
	  <para>Se voc&ecirc; <emphasis>n&atilde;o</emphasis> incluir
	    o n&uacute;mero de rastreamento, o GNATS ir&aacute; se
	    confundir e criar&aacute; um relat&oacute;rio de problema
	    completamente novo, o qual ser&aacute; atribu&iacute;do ao
	    administrador do GNATS, e ent&atilde;o o seu
	    <literal>followup</literal> ir&aacute; ficar perdido
	    at&eacute; que algu&eacute;m tenha tempo de arrumar a
	    bagun&ccedil;a, o que pode levar dias e at&eacute; mesmo
	    semanas para ocorrer.</para>
	  
	  <para>Forma errada:</para>

	  <programlisting>Subject: Sobre o PR que eu enviei</programlisting>

	  <para>Forma correta:</para>

	  <programlisting>Subject: Re: ports/12345: problemas de compila&ccedil;&atilde;o do foo/bar</programlisting>
	</note>
      </listitem>

    </itemizedlist>

    <para>Se o relat&oacute;rio de problema permanecer aberto depois
      que o problema j&aacute; tiver sido resolvido, basta enviar um
      follow-up (da forma descrita acima) informando que o PR pode
      ser fechado, e se poss&iacute;vel, explicando como e quando o
      problema foi corrigido.</para>
  </section>

  <section id="pr-problems">
    <title>Se voc&ecirc; est&aacute; tendo problemas</title>

    <para>A maioria dos PRs que chegam ao sistema &eacute; processada
      rapidamente; entretanto em alguns momentos o GNATS fica lento e
      voc&ecirc; pode n&atilde;o receber o seu email de
      confirma&ccedil;&atilde;o de imediato, levando 10 minutos ou
      mesmo um pouco mais para receb&ecirc;-lo.  Por favor, tente ser
      paciente.</para>

    <para>Al&eacute;m disso, uma vez que o GNATS recebe tudo por 
      email, &eacute; absolutamente vital que o &os; processe todas as
      mensagens que chegam utilizando filtros antispam.  Se voc&ecirc;
      n&atilde;o receber o email de confirma&ccedil;&atilde;o em
      at&eacute; duas horas, voc&ecirc; pode ter sido barrado por este
      sistema; Neste caso, por favor, entre em contato com o
      adminisrador do GNATS no endere&ccedil;o
      <email>bugmeister@FreeBSD.org</email> e pe&ccedil;a
      ajuda.</para>
    
    <note>
      <para>
	Dentre as medidas antispam que utilizamos existe uma a qual
	verifica a ader&ecirc;ncia da sua mensagem em
	rela&ccedil;&atilde;o a uma s&eacute;rie de abusos comums em
	emails baseados em HTML (embora o sistema n&atilde;o
	necessariamente invalide uma mensagem devido a mera
	inclus&atilde;o de c&oacute;digo HTML no PR).  
	Recomendamos fortemente que voc&ecirc; evite utilizar 
	emails no formato HTML quando estiver enviando um PR: 
	N&atilde;o apenas &eacute; prov&aacute;vel que a sua 
	mensagem seja bloqueada pelos filtros, como ela 
	tamb&eacute;m ir&aacute; prejudicar o banco
	de dados.  O bom e velho email em texto puro &eacute;
	fortemente preferido.</para>
    </note>

    <para>Em raras ocasi&otilde;es voc&ecirc; ir&aacute; se deparar 
      com um bug do GNATS pelo qual um PR ser&aacute; aceito, 
      receber&aacute; um n&uacute;mero de rastreamento, mas 
      n&atilde;o ir&aacute; aparecer na lista de PRs em nenhuma 
      consulta realizada no web site.  
      O que pode ter ocorrido &eacute; que o &iacute;ndice do banco de 
      dados ficou fora de sincronia com o pr&oacute;prio banco de 
      dados.  Uma forma de testar se &eacute; isto que esta 
      acontecendo com voc&ecirc; &eacute; acessar um PR individual 
      qualquer listado a partir do <ulink
      url="http://www.FreeBSD.org/cgi/query-pr.cgi">formul&aacute;rio
      de busca</ulink>, e substituir o numero do PR na URL pelo seu e
      verificar se ele carrega normalmente.  Se ele carregar, por
      favor, notifique os administradores do GNATS no endere&ccedil;o
      <email>bugmeister@FreeBSD.org</email>.  Observe que existe uma
      tarefa agendada no <literal>cron</literal> que reconstr&oacute;i
      periodicamente o banco de dados, de forma que a menos que
      voc&ecirc; esteja com pressa, nenhuma a&ccedil;&atilde;o
      ser&aacute; necess&aacute;ria.</para>
  </section>

  <section id="pr-further">
    <title>Leituras complementares</title>

    <para>Esta &eacute; uma lista com material de refer&ecirc;ncia 
      recomendado sobre boas pr&aacute;ticas para se escrever e 
      processar um relat&oacute;rio de problema.  Esta lista 
      n&atilde;o tem por objetivo ser uma lista completa.</para>

    <itemizedlist>
      <listitem>
	<para><ulink
	  url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
	  Como reportar bugs de forma efetiva</ulink>&mdash; Um 
	  excelente ensaio por Simon G. Tatham sobre a
	  elabora&ccedil;&atilde;o de relat&oacute;rios de problemas
	  eficientes (n&atilde;o &eacute; especifico sobre o 
	  &os;).</para>
      </listitem>
      <listitem>
	<para><ulink
	  url="&url.articles.pr-guidelines;/article.html">Guia de como
	  lidar com relat&oacute;rios de problemas</ulink> &mdash;
	  Uma percep&ccedil;&atilde;o valiosa sobre como os
	  desenvolvedores do FreeBSD devem lidar com os
	  relat&oacute;rios de problemas.</para>
      </listitem>
    </itemizedlist>
  </section>
</article>