pt_BR.ISO8859-1/articles/committers-guide: Content synced with en_US r52611
* pt_BR content synchronized with en_US document (rev 52611) Submitted by: dbaio Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
This commit is contained in:
Edson Brandi
parent
a658f7422c
commit
778219a258
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=52616
2 changed files with 603 additions and 542 deletions
|
|
@ -118,7 +118,7 @@
|
|||
<sect2 xml:id="pgpkeys-creating">
|
||||
<title>Criando uma chave</title>
|
||||
|
||||
<para>As chaves existentes podem ser usadas, mas elas devem ser obtidas com o <filename>doc/head/share/pgpkeys/checkkey.sh</filename> primeiro.</para>
|
||||
<para>As chaves existentes podem ser usadas, mas elas devem ser obtidas com o <filename>doc/head/share/pgpkeys/checkkey.sh</filename> primeiro. Neste caso, certifique-se que a chave contenha um ID de usuário FreeBSD.</para>
|
||||
|
||||
<para>Para quem ainda não tem uma chave Open<acronym>PGP</acronym>, ou precisa de uma nova chave para atender aos requisitos de segurança do FreeBSD, nesta seção iremos mostrar como gerar uma.</para>
|
||||
|
||||
|
|
@ -1003,7 +1003,7 @@ U stable/9/share/man/man4/netmap.4
|
|||
<sect5>
|
||||
<title>Importando para a Árvore do Fornecedor</title>
|
||||
|
||||
<para>Agora, os fontes devem ser copiados para <filename><replaceable>dist</replaceable></filename> e os comandos <command>svn add</command> e <command>svn rm</command> são usados conforme necessário:</para>
|
||||
<para>Agora, os fontes devem ser copiados para <filename><replaceable>dist</replaceable></filename> e os comandos <command>svn add</command> e <command>svn rm</command> são usados conforme necessário:</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>cd <replaceable>vendor/pf/pf-4.3</replaceable></userinput>
|
||||
<prompt>%</prompt> <userinput>tar cf - . | tar xf - -C ../dist</userinput>
|
||||
|
|
@ -1013,7 +1013,7 @@ U stable/9/share/man/man4/netmap.4
|
|||
|
||||
<para>Se algum diretório foi removido, ele terá que ser removido manualmente com o <command>svn rm</command>. Nada vai quebrar se eles não forem, mas eles permanecerão na árvore.</para>
|
||||
|
||||
<para>Verifique as propriedades em qualquer novo arquivo. Todos os arquivos de texto devem ter o <literal>svn:eol-style</literal> definido como <literal>native</literal>. Todos os arquivos binários devem ter o <literal>svn:mime-type</literal> configurado para <literal>application/octet-stream </literal>, a menos que haja um tipo de mídia mais apropriado. Arquivos executáveis devem ter <literal>svn:executable</literal> definido como <literal>*</literal>. Nenhuma outra propriedade deve existir em qualquer arquivo da árvore.</para>
|
||||
<para>Verifique as propriedades em qualquer novo arquivo. Todos os arquivos de texto devem ter o <literal>svn:eol-style</literal> definido como <literal>native</literal>. Todos os arquivos binários devem ter o <literal>svn:mime-type</literal> configurado para <literal>application/octet-stream </literal>, a menos que haja um tipo de mídia mais apropriado. Arquivos executáveis devem ter <literal>svn:executable</literal> definido como <literal>*</literal>. Nenhuma outra propriedade deve existir em qualquer arquivo da árvore.</para>
|
||||
|
||||
<para>Agora é possível fazer o commit. No entanto, é uma boa prática certificar-se de que tudo está correto, usando os comandos <command>svn stat</command> e <command>svn diff</command>.</para>
|
||||
</sect5>
|
||||
|
|
@ -1778,7 +1778,7 @@ Relnotes: yes</programlisting>
|
|||
<term>Equipe de Engenharia de Documentação <email>doceng@FreeBSD.org</email></term>
|
||||
|
||||
<listitem>
|
||||
<para>O doceng é o grupo responsável pela infraestrutura de criação de documentação, aprovando de novos committers de documentação e garantindo que o website do FreeBSD e a documentação no site FTP estão atualizados em relação à árvore <application>subversion</application>. Não é um corpo de resolução de conflitos. A grande maioria das discussões relacionadas à documentação ocorre na <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc">lista de discussão do projeto de documentação do FreeBSD</link>. Mais detalhes sobre a equipe doceng podem ser encontrados em seu <link xlink:href="https://www.FreeBSD.org/internal/doceng.html">charter</link>. Os committers interessados em contribuir com a documentação devem se familiarizar com o <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/fdp-primer/index.html">Primer do Projeto de Documentação</link>.</para>
|
||||
<para>O doceng é o grupo responsável pela infraestrutura de criação de documentação, aprovando de novos committers de documentação e garantindo que o website do FreeBSD e a documentação no site FTP estão atualizados em relação à árvore <application>subversion</application>. Não é um corpo de resolução de conflitos. A grande maioria das discussões relacionadas à documentação ocorre na <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc">lista de discussão do projeto de documentação do FreeBSD</link>. Mais detalhes sobre a equipe doceng podem ser encontrados em seu <link xlink:href="https://www.FreeBSD.org/internal/doceng.html">charter</link>. Os committers interessados em contribuir com a documentação devem se familiarizar com o <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/fdp-primer/index.html">Primer do Projeto de Documentação</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -1786,12 +1786,12 @@ Relnotes: yes</programlisting>
|
|||
<term>Bruce Evans <email>bde@FreeBSD.org</email></term>
|
||||
|
||||
<listitem>
|
||||
<para>Bruce é o Style Police-Meister. Quando você fizer um commit que poderia ter sido feito melhor, Bruce estará lá para lhe contar. Seja grato que alguém está. Bruce também é muito conhecedor dos vários padrões aplicáveis ao FreeBSD.</para>
|
||||
<para>Bruce é o Style Police-Meister. Quando você fizer um commit que poderia ter sido feito melhor, Bruce estará lá para lhe contar. Seja grato que alguém está. Bruce também é muito conhecedor dos vários padrões aplicáveis ao FreeBSD.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Glen Barber <email>gjb@FreeBSD.org</email>, Konstantin Belousov <email>kib@FreeBSD.org</email>, Bryan Drewery <email>bdrewery@FreeBSD.org</email>, Marc Fonvieille <email>blackend@FreeBSD.org</email>, Rodney Grimes <email>rgrimes@FreeBSD.org</email>, Xin Li <email>delphij@FreeBSD.org</email>, Hiroki Sato <email>hrs@FreeBSD.org</email>, Gleb Smirnoff <email>glebius@FreeBSD.org</email>, Marius Strobl <email>marius@FreeBSD.org</email>, Robert Watson <email>rwatson@FreeBSD.org</email></term>
|
||||
<term>Glen Barber <email>gjb@FreeBSD.org</email>, Konstantin Belousov <email>kib@FreeBSD.org</email>, Bryan Drewery <email>bdrewery@FreeBSD.org</email>, Marc Fonvieille <email>blackend@FreeBSD.org</email>, Rodney Grimes <email>rgrimes@FreeBSD.org</email>, Xin Li <email>delphij@FreeBSD.org</email>, Hiroki Sato <email>hrs@FreeBSD.org</email>, Gleb Smirnoff <email>glebius@FreeBSD.org</email>, Marius Strobl <email>marius@FreeBSD.org</email></term>
|
||||
|
||||
<listitem>
|
||||
<para>Estes são os membros da Equipe de Engenharia de Release <email>re@FreeBSD.org</email>. Essa equipe é responsável por definir os prazos de lançamento e por controlar o processo de release. Durante o congelamento de código, os engenheiros de release têm autoridade final sobre todas as alterações no sistema para qualquer branch que esteja com status de release pendente. Se há algo que você deseja mesclar do FreeBSD-CURRENT para o FreeBSD-STABLE (quaisquer valores que eles possam ter em um dado momento), estas são as pessoas com quem conversar sobre isso.</para>
|
||||
|
|
@ -1810,7 +1810,7 @@ Relnotes: yes</programlisting>
|
|||
<term>Garrett Wollman <email>wollman@FreeBSD.org</email></term>
|
||||
|
||||
<listitem>
|
||||
<para>Se você precisar de conselhos sobre aspectos internos obscuros da rede ou não tiver certeza de alguma mudança potencial no subsistema de rede que você tem em mente, Garrett é alguém com quem conversar. Garrett também é muito conhecedor dos vários padrões aplicáveis ao FreeBSD.</para>
|
||||
<para>Se você precisar de conselhos sobre aspectos internos obscuros da rede ou não tiver certeza de alguma mudança potencial no subsistema de rede que você tem em mente, Garrett é alguém com quem conversar. Garrett também é muito conhecedor dos vários padrões aplicáveis ao FreeBSD.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -1871,9 +1871,9 @@ Relnotes: yes</programlisting>
|
|||
<sect1 xml:id="coverity">
|
||||
<title>Disponibilidade do <trademark class="registered">Coverity</trademark> para os Committers do FreeBSD</title>
|
||||
|
||||
<para>Todos os desenvolvedores do FreeBSD podem obter acesso aos resultados da análise do <application>Coverity</application> de todo o software do Projeto FreeBSD. Todos os interessados em obter acesso aos resultados de análise das execuções automatizadas do <application>Coverity</application> podem se inscrever em <uri xlink:href="http://scan.coverity.com/">Coverity Scan</uri>.</para>
|
||||
<para>Todos os desenvolvedores do FreeBSD podem obter acesso aos resultados da análise do <application>Coverity</application> de todo o software do Projeto FreeBSD. Todos os interessados em obter acesso aos resultados de análise das execuções automatizadas do <application>Coverity</application> podem se inscrever em <uri xlink:href="http://scan.coverity.com/">Coverity Scan</uri>.</para>
|
||||
|
||||
<para>O wiki do FreeBSD inclui um mini-guia para desenvolvedores interessados em trabalhar com os relatórios de análise do <trademark class="registered">Coverity</trademark>: <uri xlink:href="https://wiki.freebsd.org/CoverityPrevent">https://wiki.freebsd.org/CoverityPrevent</uri>. Por favor observe que este mini-guia só pode ser lido por desenvolvedores do FreeBSD, então se você não puder acessar esta página, você terá que pedir a alguém para adicioná-lo à lista de acesso apropriada do Wiki.</para>
|
||||
<para>O wiki do FreeBSD inclui um mini-guia para desenvolvedores interessados em trabalhar com os relatórios de análise do <trademark class="registered">Coverity</trademark>: <uri xlink:href="https://wiki.freebsd.org/CoverityPrevent">https://wiki.freebsd.org/CoverityPrevent</uri>. Por favor observe que este mini-guia só pode ser lido por desenvolvedores do FreeBSD, então se você não puder acessar esta página, você terá que pedir a alguém para adicioná-lo à lista de acesso apropriada do Wiki.</para>
|
||||
|
||||
<para>Finalmente, todos os desenvolvedores do FreeBSD que usarão o <trademark class="registered">Coverity</trademark> são sempre encorajados a pedir mais detalhes e informações sobre o uso, publicando quaisquer perguntas na lista de discussão dos desenvolvedores do FreeBSD.</para>
|
||||
</sect1>
|
||||
|
|
@ -1905,7 +1905,7 @@ Relnotes: yes</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que tenha tempo suficiente de teste. O engenheiro de release tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito para o mantenedor na regra #5.</para>
|
||||
<para>As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que tenha tempo suficiente de teste. O engenheiro de release tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito para o mantenedor na regra #5.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -1925,7 +1925,7 @@ Relnotes: yes</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Não faça commit de nada sob as árvores <filename>src/contrib</filename>, <filename>src/crypto</filename>, ou <filename>src/sys/contrib</filename> sem aprovação <emphasis>explicita</emphasis> dos respectivos mantenedores.</para>
|
||||
<para>Não commit em software contribuído sem a aprovação <emphasis>explicita</emphasis> dos respectivos mantenedores.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
|
@ -1978,7 +1978,7 @@ Relnotes: yes</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que possa ter tempo suficiente de teste. O engenheiro de lançamento tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito na regra #5.</para>
|
||||
<para>As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que possa ter tempo suficiente de teste. O engenheiro de lançamento tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito na regra #5.</para>
|
||||
|
||||
<para>Este é outro problema do tipo <quote>não discuta sobre isso</quote>, já que é o engenheiro de release quem é o responsável final (e é espancado) se uma mudança for ruim. Por favor, respeite isso e dê ao engenheiro de release a sua total cooperação quando se trata do branch FreeBSD-STABLE. O gerenciamento do FreeBSD-STABLE pode frequentemente parecer excessivamente conservador para o observador casual, mas também deve ter em mente o fato de que o conservadorismo deve ser a marca do FreeBSD-STABLE e regras diferentes aplicam-se lá do que no FreeBSD-CURRENT. Também não há sentido em fazer com que o FreeBSD-CURRENT seja um campo de testes se as alterações forem mescladas no FreeBSD-STABLE imediatamente. Mudanças precisam de uma chance de serem testadas pelos desenvolvedores do FreeBSD-CURRENT, então espere algum tempo antes da fusão, a menos que a correção do FreeBSD-STABLE seja crítica, sensível ao tempo ou óbvia a ponto de tornar desnecessário testes adicionais (correções ortográficas nas páginas de manual) correções de erros / erros de digitação, etc.) Em outras palavras, aplique o bom senso.</para>
|
||||
|
||||
|
|
@ -2013,14 +2013,15 @@ Relnotes: yes</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Não faça o commit de nada sob as árvores <filename>src/contrib</filename>, <filename>src/crypto</filename>, e <filename>src/sys/contrib</filename> sem a aprovação <emphasis>explicita</emphasis> dos respectivos mantenedores.</para>
|
||||
<para>Não commit em software contribuído sem a aprovação <emphasis>explicita</emphasis> dos respectivos mantenedores.</para>
|
||||
|
||||
<para>As árvores mencionadas acima são para software contribuído geralmente importado para um branch de fornecedor. fazer o commit de algo lá, mesmo que não retire o arquivo branch do fornecedor, pode causar dores de cabeça desnecessárias para os responsáveis pela manutenção desse software em particular. Assim, a menos que você tenha aprovação <emphasis>explícita</emphasis> do mantenedor (ou você é o mantenedor), <emphasis>não</emphasis> faça commit lá!</para>
|
||||
<para>Software contribuído é qualquer código que esteja sob as árvores <filename>src/contrib</filename>, <filename>src/crypto</filename>, ou <filename>src/sys/contrib</filename>.</para>
|
||||
|
||||
<!-- FIXME: this paragraph should be rewritten -->
|
||||
<para>Por favor note que isto não significa que você não deve tentar melhorar o software em questão; você ainda é mais que bem-vindo para fazer isso. O ideal é enviar seus patches ao fornecedor. Se suas alterações são específicas para o FreeBSD, fale com o mantenedor; eles podem estar dispostos a aplicá-los localmente. Mas faça o que fizer, <emphasis>não</emphasis> faça o commit lá você mesmo!</para>
|
||||
<para>As árvores mencionadas acima são para software contribuído geralmente importado para um branch de fornecedor. Fazer o commit de algo lá pode causar dores de cabeça desnecessárias quando for importado novas versões do software. Uma regra geral é considerar enviar os patches upstream diretamente para o fornecedor. Patches podem ser committados primeiramente no FreeBSD, desde que tenha a permissão do mantenedor.</para>
|
||||
|
||||
<para>Entre em contato com o Core Team <email>core@FreeBSD.org</email> se você quiser assumir a manutenção de uma parte não mantida da árvore.</para>
|
||||
<para>As razões para modificar o software upstream variam entre querer controle estrito sobre uma dependência fortemente acoplada à falta de portabilidade na distribuição do repositório canônico do seu código. Independentemente do motivo, o esforço para minimizar a carga de manutenção do fork é útil para outros mantenedores. Evite realizar commits de alterações triviais ou cosméticas nos arquivos, pois isso dificulta cada merge: esses patches precisam ser verificados manualmente a cada importação.</para>
|
||||
|
||||
<para>Se uma parte específica do software não tiver um mantenedor, você é incentivado a assumir a propriedade. Se você não tiver certeza sobre o mantenedor atual, envie um email para a <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-arch">lista de email de arquitetura e design do FreeBSD</link> e pergunte.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
|
@ -2160,7 +2161,7 @@ Relnotes: yes</programlisting>
|
|||
<sect2>
|
||||
<title>Tier 2: Arquiteturas em Desenvolvimento</title>
|
||||
|
||||
<para>As plataformas de Tier 2 não são suportadas pelas equipes do oficial de segurança e pelas as equipes de engenharia de release. Os mantenedores de plataformas são responsáveis pelo suporte de toolchain na árvore. Espera-se que os mantenedores de toolchain trabalhem com os mantenedores da plataforma para refinar essas mudanças. Os principais novos componentes de toolchain têm permissão para quebrar o suporte para arquiteturas de Tier 2 se as alterações locais do FreeBSD não tiverem sido incorporadas ao upstream. Espera-se que os mantenedores de toolchain forneçam uma rápida revisão de quaisquer alterações propostas e não possam bloquear, por meio de sua inação, as mudanças que vão para a árvore. Novos recursos adicionados ao FreeBSD devem ser viáveis de implementar nessas plataformas, mas uma implementação não é necessária antes que o recurso possa ser adicionado à árvore de códigos fonte do FreeBSD. Novos recursos que podem ser difíceis de implementar em arquiteturas de Tier 2 devem fornecer um meio de desabilitá-los nessas arquiteturas. Pode se fazer o commit de uma implementação de uma arquitetura de Tier 2 na árvore principal do FreeBSD, desde que não interfira com o trabalho de produção nas plataformas de Tier 1, ou substancialmente com outras plataformas de Tier 2. Antes que uma plataforma Tier 2 possa ser adicionada à árvore de código fonte do FreeBSD, a plataforma deve ser capaz de inicializar em modo multiusuário em hardware real. Geralmente, deve haver pelo menos três desenvolvedores ativos trabalhando na plataforma.</para>
|
||||
<para>As plataformas de Tier 2 não são suportadas pelas equipes do oficial de segurança e pelas as equipes de engenharia de release. Os mantenedores de plataformas são responsáveis pelo suporte de toolchain na árvore. Espera-se que os mantenedores de toolchain trabalhem com os mantenedores da plataforma para refinar essas mudanças. Os principais novos componentes de toolchain têm permissão para quebrar o suporte para arquiteturas de Tier 2 se as alterações locais do FreeBSD não tiverem sido incorporadas ao upstream. Espera-se que os mantenedores de toolchain forneçam uma rápida revisão de quaisquer alterações propostas e não possam bloquear, por meio de sua inação, as mudanças que vão para a árvore. Novos recursos adicionados ao FreeBSD devem ser viáveis de implementar nessas plataformas, mas uma implementação não é necessária antes que o recurso possa ser adicionado à árvore de códigos fonte do FreeBSD. Novos recursos que podem ser difíceis de implementar em arquiteturas de Tier 2 devem fornecer um meio de desabilitá-los nessas arquiteturas. Pode se fazer o commit de uma implementação de uma arquitetura de Tier 2 na árvore principal do FreeBSD, desde que não interfira com o trabalho de produção nas plataformas de Tier 1, ou substancialmente com outras plataformas de Tier 2. Antes que uma plataforma Tier 2 possa ser adicionada à árvore de código fonte do FreeBSD, a plataforma deve ser capaz de inicializar em modo multiusuário em hardware real. Geralmente, deve haver pelo menos três desenvolvedores ativos trabalhando na plataforma.</para>
|
||||
|
||||
<para>As arquiteturas de Tier 2 geralmente são sistemas destinados ao suporte Tier 1, mas que ainda estão em desenvolvimento. As arquiteturas que atingem o fim da vida útil também podem ser movidas do status de Tier 1 para o status de Tier 2 à medida que a disponibilidade de recursos para continuar a manter o sistema em um estado de Qualidade de Produção diminui. Arquiteturas de nicho bem suportadas também podem ser de Tier 2.</para>
|
||||
|
||||
|
|
@ -2512,7 +2513,7 @@ MFH: <replaceable>2014Q1 (browser blanket)</replaceable></programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>As seguintes aprovações gerais estão em vigor:</para>
|
||||
<para>As seguintes aprovações implícitas para merge nas branches trimestrais estão em vigor:</para>
|
||||
|
||||
<important>
|
||||
<para>Estas correções <emphasis>devem</emphasis> ser testadas na branch trimestral.</para>
|
||||
|
|
@ -2560,7 +2561,7 @@ MFH: <replaceable>2014Q1 (browser blanket)</replaceable></programlisting>
|
|||
</itemizedlist>
|
||||
|
||||
<important>
|
||||
<para>Commits que não são cobertos por essas aprovações gerais sempre exigem aprovação explícita da Equipe de Segurança do Ports <email>ports-secteam@FreeBSD.org</email> ou da Equipe de Gerenciamento de Ports <email>portmgr@FreeBSD.org</email>.</para>
|
||||
<para>Commits que não são cobertos por essas aprovações implícitas sempre exigem aprovação explícita da Equipe de Segurança do Ports <email>ports-secteam@FreeBSD.org</email> ou da Equipe de Gerenciamento do Ports <email>portmgr@FreeBSD.org</email>.</para>
|
||||
</important>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
|
@ -2776,6 +2777,34 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
|
|||
<qandadiv xml:id="ports-qa-misc-questions">
|
||||
<title>Perguntas Diversas</title>
|
||||
|
||||
<qandaentry xml:id="ports-qa-misc-blanket-approval">
|
||||
<question>
|
||||
<para>Existe alguma alteração para a qual possa ser feito o commit sem a aprovação do mantenedor?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>A aprovação implícita para a maioria dos ports se aplica a estes tipos de correções:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A maioria das alterações de infraestrutura para um port (isso é, modernizar, sem alterar funcionalidades). Por exemplo, a aprovação implícita inclui a conversão de novas macros <varname>USES</varname>, ativar verbosidade de compilação e alterações para novas sintaxes de sistema do ports.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Trivialidades e correções <emphasis>testadas</emphasis> de compilação e execução.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<important>
|
||||
<para>Exceções para isso são qualquer coisa que seja mantido pela Equipe de Gerenciamento do Ports <email>portmgr@FreeBSD.org</email> ou pelo Time de Oficiais de Segurança <email>security-officer@FreeBSD.org</email>. Nenhum commit não autorizado pode ser feito em ports mantidos por esses grupos.</para>
|
||||
</important>
|
||||
|
||||
<warning>
|
||||
<para>Aprovação implícita não se aplica a ports que são mantidos por equipes como <email role="nolink">autotools@FreeBSD.org</email>, <email role="nolink">x11@FreeBSD.org</email>, <email role="nolink">gnome@FreeBSD.org</email>, ou <email role="nolink">kde@FreeBSD.org</email>. Essas equipes usam repositórios externos e podem ter trabalhos que entrariam em conflito com mudanças que normalmente seriam abrangidas pela aprovação implícita.</para>
|
||||
</warning>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry xml:id="ports-qa-misc-correctly-building">
|
||||
<question>
|
||||
<para>Como sei se meu port está sendo compilado corretamente ou não?</para>
|
||||
|
|
@ -2930,9 +2959,9 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
|
|||
|
||||
<para>O acesso do Google Analytics <emphasis>não</emphasis> é arbitrariamente permitido - o acesso deve ser solicitado, votado pela Equipe de Engenharia de Documentação <email>doceng@FreeBSD.org</email> e explicitamente concedido.</para>
|
||||
|
||||
<para>Solicitações de acesso aos dados do Google Analytics devem incluir uma finalidade específica. Por exemplo, uma razão válida para solicitar acesso seria <quote>para ver os navegadores web usados com mais freqüência pelos visitantes do website do FreeBSD para garantir que as velocidades de renderização da página sejam aceitáveis.</quote></para>
|
||||
<para>Solicitações de acesso aos dados do Google Analytics devem incluir uma finalidade específica. Por exemplo, uma razão válida para solicitar acesso seria <quote>para ver os navegadores web usados com mais freqüência pelos visitantes do website do FreeBSD para garantir que as velocidades de renderização da página sejam aceitáveis.</quote></para>
|
||||
|
||||
<para>Por outro lado, <quote>ver quais navegadores são usados com mais freqüência</quote> (sem declarar <emphasis>por que</emphasis>) seria rejeitado.</para>
|
||||
<para>Por outro lado, <quote>ver quais navegadores são usados com mais freqüência</quote> (sem declarar <emphasis>por que</emphasis>) seria rejeitado.</para>
|
||||
|
||||
<para>Todas as solicitações devem incluir o período de tempo para o qual os dados seriam requisitados. Por exemplo, deve ser explicitamente declarado se os dados solicitados seriam requisitados em um período de tempo que abranja um período de 3 semanas, ou se o pedido seria para acessar apenas uma vez.</para>
|
||||
|
||||
|
|
@ -2964,24 +2993,6 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
|
|||
<title>Perguntas Diversas</title>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>Por que as mudanças triviais ou cosméticas nos arquivos de um branch de um fornecedor são uma má ideia?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Porque a partir de agora, cada nova release do fornecedor desse arquivo precisará ter os patches integrados manualmente.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A partir de agora, cada nova release do fornecedor desse arquivo precisará ter correções <emphasis>verificadas</emphasis> manualmente.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>Como adiciono um novo arquivo a uma branch?</para>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue