svn commit: r39503 - in head/pt_BR.ISO8859-1/articles: . problem-reports

Gabor Kovesdan gabor at FreeBSD.org
Wed Sep 5 05:38:12 UTC 2012


Author: gabor
Date: Wed Sep  5 05:38:11 2012
New Revision: 39503
URL: http://svn.freebsd.org/changeset/doc/39503

Log:
  - Add new Brazilian Portuguese translation of the problem-reports article
  
  PR:		docs/170672
  Submitted by:	Edson Brandi <ebrandi at fugspbr.org>
  Obtained from:	The FreeBSD Brazilian Portuguese Documentation Project
  		(http://doc.fug.com.br)

Added:
  head/pt_BR.ISO8859-1/articles/problem-reports/
  head/pt_BR.ISO8859-1/articles/problem-reports/Makefile   (contents, props changed)
  head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml   (contents, props changed)
Modified:
  head/pt_BR.ISO8859-1/articles/Makefile

Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile	Wed Sep  5 05:32:52 2012	(r39502)
+++ head/pt_BR.ISO8859-1/articles/Makefile	Wed Sep  5 05:38:11 2012	(r39503)
@@ -11,6 +11,7 @@
 SUBDIR =
 SUBDIR+= contributing
 SUBDIR+= linux-users
+SUBDIR+= problem-reports
 
 DOC_PREFIX?= ${.CURDIR}/../..
 .include "${DOC_PREFIX}/share/mk/doc.project.mk"

Added: head/pt_BR.ISO8859-1/articles/problem-reports/Makefile
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/problem-reports/Makefile	Wed Sep  5 05:38:11 2012	(r39503)
@@ -0,0 +1,24 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: Writing FreeBSD Problem Reports
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS=	article.sgml
+
+URL_RELPREFIX?=	../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"

Added: head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml	Wed Sep  5 05:38:11 2012	(r39503)
@@ -0,0 +1,1644 @@
+<!--
+  The FreeBSD Documentation Project
+  The FreeBSD Brazilian Portuguese Documentation Project
+
+  Original revision: r38826 
+-->
+
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
+<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//PTBR">
+%articles.ent;
+]>
+
+<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 at 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>No template do email voc&ecirc; ir&aacute; encontrar os
+	dois seguintes campos de linha &uacute;nica:</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>
+
+      </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>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>Os grandes problemas de seguran&ccedil;a

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***


More information about the svn-doc-all mailing list