- <para><emphasis>Não deixe a linha <quote>Summary</quote> vazia. </emphasis>Os PRs são enviados para listas de discussão no mundo todo (nas quais a <quote>Synopsis</quote> é usada para a linha de <literal>Subject:</literal>), além de serem armazenadas em um banco de dados. Qualquer pessoa que vier a navegar no banco de dados pelas sinopses, e encontrar um PR com a linha de assunto em branco, tende a pulá-lo. Lembre-se que os PRs permanecem na base de dados até que sejam fechados por alguém; os anônimos normalmente irão desaparecer em meio ao ruído.</para>
+ <para><emphasis>Não deixe a linha <quote>Summary</quote> vazia. </emphasis>Os PRs são enviados para listas de discussão no mundo todo (onde o <quote>Summary</quote> é usado para a linha de <literal>Subject:</literal>), além de serem armazenadas em um banco de dados. Qualquer pessoa que vier a navegar no banco de dados pelas sinopses, e encontrar um PR com a linha de assunto em branco, tende a pulá-lo. Lembre-se que os PRs permanecem na base de dados até que sejam fechados por alguém; os anônimos normalmente irão desaparecer em meio ao ruído.</para>
</listitem>
<listitem>
- <para><emphasis>Evite usar uma <quote>Sinopse</quote> (Sinopse) fraca. </emphasis> Você não deve presumir que alguém que esteja lendo seu PR conheça o contexto que motivou o seu envio, desta forma, quanto mais informação você fornecer, melhor. Por exemplo, a parte do sistema o problema se aplica? O problema ocorre durante a instalação ou durante a execução do sistema? Para ilustrar, em vez de usa <literal>Sinopse: o portupgrade está quebrado</literal>, veja o quanto mais informativo isso parece: <literal> Sinopse: port ports-mgmt/portupgrade gerando coredumps on -current</literal>. (No caso de um port, é especialmente útil ter tanto o nome da categoria quanto o nome do port na linha <quote>Sinopse</quote>.)</para>
+ <para><emphasis>Evite usar um <quote>Summary</quote> (Sumário) fraco. </emphasis> Você não deve presumir que alguém que esteja lendo seu PR conheça o contexto que motivou o seu envio, desta forma, quanto mais informação você fornecer, melhor. Por exemplo, em qual parte do sistema o problema se aplica? O problema ocorre durante a instalação ou durante a execução do sistema? Para ilustrar, em vez de usar <literal>Summary: o portupgrade está quebrado</literal>, veja o quanto mais informativo isso parece: <literal> Summary: port ports-mgmt/portupgrade gerando coredumps no -current</literal>. (No caso de um port, é especialmente útil ter tanto o nome da categoria quanto o nome do port na linha <quote>Summary</quote>.)</para>
</listitem>
<listitem>
- <para><emphasis>Se você tem um patch, mencione-o.</emphasis> Um PR com um patch incluído é muito mais provável de ser analisado do que um sem. Se você está incluindo um, coloque a palavra <literal>[patch]</literal> (incluindo os colchetes) no início da linha de <quote>Sinopse</quote>. (Embora não seja obrigatório usar exatamente essa palavra, por convenção, essa é a que é usada.)</para>
+ <para><emphasis>Se você tem um patch, mencione-o.</emphasis> Um PR com um patch incluído é muito mais provável de ser analisado do que um sem. Por favor, inclua a palavra-chave <literal>patch</literal> no Bugzilla.</para>
</listitem>
<listitem>
- <para><emphasis>Se você é um mantenedor, diga.</emphasis> Se você está mantendo uma parte do código fonte (por exemplo, um port), você pode considerar adicionar as palavras <literal>[atualização do mantenedor]</literal> (incluindo os colchetes) no início da sua linha de sinopse, e você definitivamente deve definir a <quote>Class</quote> (Classe) do seu PR para <literal>maintainer-update</literal>. Desta forma, qualquer committer que lide com seu PR não terá que verificar o Makefile do port, para certificar-se de que a atualização foi enviada pelo maintainer.</para>
+ <para><emphasis>Se você é um mantenedor, informe.</emphasis> Se você está mantendo uma parte do código fonte (por exemplo, um port existente), você deve definir o campo <quote>Class</quote> do seu PR para <literal>maintainer-update</literal>. Desta forma, qualquer committer que lide com seu PR não terá que verificar.</para>
</listitem>
<listitem>
@@ -246,7 +246,7 @@
<section xml:id="pr-writing-attaching-patches">
<title>Anexando Patches ou Arquivos</title>
- <para>Ao anexar um patch, certifique-se de usar <option>-u</option> com <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> para criar ou unificar o diff e certificar-se de especificar os números de revisão exatos do SVN dos arquivos que você modificou para que os desenvolvedores que lerem seu relatório possam aplicá-los facilmente. Para problemas com o kernel ou com os utilitários de base, um patch para o FreeBSD-CURRENT (a branch HEAD do Subversion) é o preferido, já que todo código novo deve ser aplicado e testado lá primeiro. Após testes apropriados ou substanciais terem sido feitos, o código será mesclado/migrado para a branch FreeBSD-STABLE.</para>
+ <para>Ao anexar um patch, certifique-se de usar <command>svn diff</command> ou <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> com o argumento <option>-u</option> para criar ou unificar o diff e certificar-se de especificar os números de revisão exatos do SVN dos arquivos que você modificou para que os desenvolvedores que lerem seu relatório possam aplicá-los facilmente. Para problemas com o kernel ou com os utilitários de base, um patch para o FreeBSD-CURRENT (a branch HEAD do Subversion) é o preferido, já que todo código novo deve ser aplicado e testado lá primeiro. Após testes apropriados ou substanciais terem sido feitos, o código será mesclado/migrado para a branch FreeBSD-STABLE.</para>
<para>Se você anexar um patch inline, em vez de um anexo, observe que o problema mais comum, de longe, é a tendência de alguns programas de email renderizar tabs como espaços, o que ira arruinar completamente qualquer coisa destinada a fazer parte de um Makefile.</para>
@@ -269,8 +269,6 @@
<itemizedlist>
<listitem>
<para><emphasis>Summary (Sumário):</emphasis> Preencha com uma descrição breve e precisa do problema. A sinopse é usada como assunto do email do relatório de problemas. A sinopse é usada em listagens e resumos de relatórios de problemas; relatórios de problemas com sinopses obscuras tendem a ser ignoradas.</para>
-
- <para>Como mencionado acima, se o seu relatório de problemas incluir um patch, faça com que a sinopse comece com <literal>[patch]</literal> (incluindo os colchetes); se este for um PR para um ports do qual você é o mantenedor, você pode considerar adicionar <literal>[maintainer update]</literal> (incluindo os colchetes).</para>
</listitem>
<listitem>
@@ -322,7 +320,7 @@
</listitem>
<listitem>
- <para>Se estiver convencido de que o problema ocorrerá apenas sob a arquitetura do processador que você está usando, selecione uma das categorias específicas da arquitetura: geralmente <literal>i386</literal> para máquinas compatíveis com Intel 32 bits; <literal>amd64</literal> para máquinas AMD rodando em de 64 bits (isto também inclui máquinas compatíveis com Intel rodando em modo EMT64); e menos comumente, as arquiteturas <literal>arm</literal>, <literal>ia64</literal>, <literal>powerpc</literal>.</para>
+ <para>Se estiver convencido de que o problema ocorrerá apenas sob a arquitetura do processador que você está usando, selecione uma das categorias específicas da arquitetura: geralmente <literal>i386</literal> para máquinas compatíveis com Intel 32 bits; <literal>amd64</literal> para máquinas AMD rodando em 64 bits (isto também inclui máquinas compatíveis com Intel rodando em modo EMT64); e menos comumente, as arquiteturas <literal>arm</literal> ou <literal>powerpc</literal>.</para>
<note>
<para>Estas categorias são muitas vezes mal utilizadas para problemas definidos como <quote>Eu não sei</quote>. Em vez de adivinhar, por favor apenas use a categoria <literal>misc</literal>.</para>