pt_BR/articles/committers-guide: Sync with en_US r53671
Obtained from: https://translate-dev.freebsd.org/
This commit is contained in:
Edson Brandi
parent
b947d40b08
commit
c0d1836765
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=53731
2 changed files with 1643 additions and 1251 deletions
|
|
@ -1008,7 +1008,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>
|
||||
|
|
@ -1018,7 +1018,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>
|
||||
|
|
@ -1341,7 +1341,7 @@ freebsd-mfc-after = 2 weeks</programlisting>
|
|||
<step>
|
||||
<title>Opcional: Ative a sua conta na Wiki</title>
|
||||
|
||||
<para><link xlink:href="https://wiki.freebsd.org">Conta no Wiki do FreeBSD</link> - Uma conta no wiki permite que compartilhe projetos e ideias. Aqueles que ainda não têm uma conta podem seguir as instruções da <link xlink:href="https://wiki.freebsd.org/AboutWiki">Página Sobre a Wiki</link> para obter uma. Entre em contato com <email>clusteradm@FreeBSD.org</email> se precisar de ajuda com sua conta no Wiki.</para>
|
||||
<para><link xlink:href="https://wiki.freebsd.org">Conta no Wiki do FreeBSD</link> - Uma conta no wiki permite que compartilhe projetos e ideias. Aqueles que ainda não têm uma conta podem seguir as instruções da <link xlink:href="https://wiki.freebsd.org/AboutWiki">Página Sobre a Wiki</link> para obter uma. Entre em contato com <email>wikiadmin@FreeBSD.org</email> se precisar de ajuda com sua conta no Wiki.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
|
|
@ -1388,15 +1388,14 @@ freebsd-mfc-after = 2 weeks</programlisting>
|
|||
</note>
|
||||
|
||||
<sect3 xml:id="smtp-setup">
|
||||
<title>Configuração de acesso SMTP</title>
|
||||
<title>Configuração de acesso SMTP</title>
|
||||
|
||||
<para>Para aqueles dispostos a enviar mensagens de e-mail através da infraestrutura do FreeBSD.org, siga as instruções abaixo:</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Aponte seu cliente de e-mail para <literal><systemitem class="fqdomainname">smtp.FreeBSD.org</systemitem>:587</literal>.</para>
|
||||
</step>
|
||||
|
||||
<para>Aponte seu cliente de e-mail para <literal><systemitem class="fqdomainname">smtp.FreeBSD.org</systemitem>:587</literal>.</para></step>
|
||||
|
||||
<step>
|
||||
<para>Habilite o STARTTLS.</para>
|
||||
</step>
|
||||
|
|
@ -1423,8 +1422,7 @@ freebsd-mfc-after = 2 weeks</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Um cabeçalho será anexado com o nome de usuário do SASL: (<literal>Authenticated sender: <replaceable>username</replaceable></literal>).</para>
|
||||
</listitem>
|
||||
<para>Um cabeçalho será anexado com o nome de usuário do SASL: (<literal>Authenticated sender: <replaceable>username</replaceable></literal>).</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>O host possui vários limites de taxa para reduzir as tentativas de força bruta.</para>
|
||||
|
|
@ -1639,6 +1637,11 @@ smtpd_sender_restrictions = reject_known_sender_login_mismatch</programlisting>
|
|||
<entry>Se a alteração estiver relacionada a uma vulnerabilidade de segurança ou exposição de segurança, inclua uma ou mais referências ou uma descrição do problema. Se possível, inclua um URL VuXML ou um ID CVE.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>Evento:</literal></entry>
|
||||
<entry>Descrição para o evento em que essa confirmação foi feita. Se este for um evento recorrente, adicione o ano ou até mesmo o mês. Por exemplo, isso pode ser <literal> FooBSDcon 2019 </literal>. A idéia por trás dessa linha é dar reconhecimento a conferências, reuniões e outros tipos de reuniões e mostrar que elas são úteis. Por favor, não use a linha <literal> Patrocinado por: </literal> para isso, pois isso significa que as organizações patrocinam determinados recursos ou desenvolvedores que trabalham neles.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>Differential Revision:</literal></entry>
|
||||
<entry>A URL completa da revisão do Phabricator. Esta linha <emphasis> deve ser a última linha </emphasis>. Por exemplo: <literal>https://reviews.freebsd.org/D1708</literal>.</entry>
|
||||
|
|
@ -1925,7 +1928,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>
|
||||
|
||||
|
|
@ -1933,7 +1936,7 @@ 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>
|
||||
|
||||
|
|
@ -1957,7 +1960,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>
|
||||
|
||||
|
|
@ -2018,9 +2021,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>
|
||||
|
|
@ -2052,7 +2055,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>
|
||||
|
|
@ -2125,7 +2128,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>
|
||||
|
||||
|
|
@ -2153,9 +2156,6 @@ Relnotes: yes</programlisting>
|
|||
<listitem>
|
||||
<para>Teste suas alterações antes de fazer o commit.</para>
|
||||
|
||||
<!-- XXX Needs update re sparc64 + pc98
|
||||
Also, needs more details on which machines are available for testing
|
||||
-->
|
||||
<para>Isso pode parecer óbvio, mas se realmente fosse tão óbvio, provavelmente não veríamos tantos casos de pessoas claramente não fazendo isso. Se suas mudanças são para o kernel, certifique-se de que você ainda pode compilar o GENERIC e o LINT. Se as suas alterações estiverem em outro lugar, certifique-se de que você ainda pode fazer um "make world". Se as alterações forem feitas em uma branch, certifique-se de que seu teste ocorra com uma máquina que esteja executando esse código. Se você tiver uma alteração que também possa quebrar outra arquitetura, verifique e teste em todas as arquiteturas suportadas. Por favor, consulte a <link xlink:href="https://www.FreeBSD.org/internal/">Página Interna do FreeBSD</link> para obter uma lista dos recursos disponíveis. À medida que outras arquiteturas são adicionadas à lista de plataformas suportadas do FreeBSD, os recursos de teste compartilhados apropriados serão disponibilizados.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -2282,67 +2282,182 @@ Relnotes: yes</programlisting>
|
|||
<sect2>
|
||||
<title>Declaração de Intenção Geral</title>
|
||||
|
||||
<para>O projeto FreeBSD tem como objetivo a "qualidade comercial de produção off-the-shelf (COTS) para workstations, servidores e sistemas embarcados de ponta". Mantendo o foco em um conjunto restrito de arquiteturas de interesse nesses ambientes, o Projeto FreeBSD é capaz de manter altos níveis de qualidade, estabilidade e desempenho, bem como de minimizar a carga de várias equipes de suporte no projeto, como a equipe de ports, a equipe de documentação, o oficial de segurança e as equipes de engenharia de release. A diversidade no suporte de hardware amplia as opções para os consumidores do FreeBSD oferecendo novos recursos e oportunidades de uso (como suporte a CPUs de 64 bits, uso em ambientes embarcados, etc.), mas esses benefícios devem sempre ser cuidadosamente considerados em termos do custo de manutenção no mundo real associado ao suporte adicional à plataforma.</para>
|
||||
<para>O projeto FreeBSD tem como objetivo a "qualidade comercial de produção off-the-shelf (COTS) para workstations, servidores e sistemas embarcados de ponta". Mantendo o foco em um conjunto restrito de arquiteturas de interesse nesses ambientes, o Projeto FreeBSD é capaz de manter altos níveis de qualidade, estabilidade e desempenho, bem como de minimizar a carga de várias equipes de suporte no projeto, como a equipe de ports, a equipe de documentação, o oficial de segurança e as equipes de engenharia de release. A diversidade no suporte de hardware amplia as opções para os consumidores do FreeBSD oferecendo novos recursos e oportunidades de uso, mas esses benefícios devem sempre ser cuidadosamente considerados em termos do custo de manutenção no mundo real associado ao suporte adicional à plataforma.</para>
|
||||
|
||||
<para>O projeto FreeBSD diferencia as plataformas em quatro níveis. Cada tier inclui uma especificação dos requisitos para que uma arquitetura esteja nesse nível, além de especificar as obrigações dos desenvolvedores em relação à plataforma. Além disso, uma política é definida em relação às circunstâncias necessárias para alterar o tier de uma arquitetura.</para>
|
||||
<para>O projeto FreeBSD diferencia plataforma alvos em quatro camadas. Cada camada inclui uma lista de garantias que os consumidores podem confiar , bem como as obrigações por Projeto e desenvolvedores para cumprir essas garantias. Esta lista define o mínimo de garantia por cada camada. O Projeto e desenvolvedores podem prover leveis de suporte adicionais além da garantia mínima dada a uma camada, mas tais suportes adicionais não tem garantias. Cada plataforma alvo é designada para uma camada especifica para cada ramificação stable. Como resultado, a plataforma alvo poderia ser designada para diferentes camadas em ramificações stable concorrentes.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tier 1: Arquiteturas Suportadas Completamente</title>
|
||||
<title>Plataformas Alvo</title>
|
||||
|
||||
<para>Plataformas de nível 1 são completamente suportadas pelas equipes de oficiais de segurança, engenharia de release e equipe de manutenção do toolchain. Novos recursos adicionados ao sistema operacional devem ser totalmente funcionais em todas as arquiteturas Tier 1 para cada release (recursos que são inerentemente específicos da arquitetura, como suporte a drivers de dispositivo de hardware, podem estar isentos desse requisito). Em geral, todas as plataformas de Tier 1 devem ter suporte a automação compilação e teste no cluster do FreeBSD.org ou facilmente disponíveis para todos os desenvolvedores. Plataformas embarcadas podem substituir um emulador disponível no cluster do FreeBSD.org por hardware real.</para>
|
||||
<para>O suporte para uma plataforma de hardware consiste em dois componentes: suporte ao kernel e interfaces binárias de aplicativos (ABIs) do usuário. O suporte do kernel à plataforma inclui os itens necessários para executar um kernel do FreeBSD em uma plataforma de hardware, como gerenciamento de memória virtual dependente de máquina e drivers de dispositivo. Uma ABI especifica uma interface para os processos do usuário interagirem com o kernel do FreeBSD e as bibliotecas do sistema base. Uma ABI inclui interfaces de chamada do sistema, o layout e a semântica de estruturas de dados públicos e o layout e a semântica de argumentos transmitidos às sub-rotinas. Alguns componentes de uma ABI podem ser definidos por especificações tais como o layout dos objetos de exceção C ++ ou as convenções de chamada para funções C.</para>
|
||||
|
||||
<para>Espera-se que as arquiteturas de Tier 1 estejam com Qualidade de Produção em relação a todos os aspectos do sistema operacional FreeBSD, incluindo ambientes de instalação e desenvolvimento.</para>
|
||||
<para>Um kernel do FreeBSD também usa uma ABI (às vezes chamada de Interface Binária do Kernel (KBI)) que inclui a semântica e layouts de estruturas de dados públicos e o layout e semântica de argumentos para funções públicas dentro do próprio kernel.</para>
|
||||
|
||||
<para>Espera-se que as arquiteturas de Tier 1 sejam completamente integradas na árvore de código e tenham todos os recursos necessários para produzir um sistema inteiro relevante para essa arquitetura alvo. Arquiteturas de Tier 1 geralmente têm pelo menos 6 desenvolvedores ativos.</para>
|
||||
<para>Um kernel do FreeBSD pode suportar múltiplas ABIs de usuário. Por exemplo, o kernel amd64 do FreeBSD suporta as ABIs de usuário do FreeBSD amd64 e i386, bem como as ABIs de usuário do Linux x86_64 e i386. Um kernel do FreeBSD deve suportar uma ABI <quote>nativa</quote> como a ABI padrão. A <quote>ABI</quote> nativa geralmente compartilha certas propriedades com a ABI do kernel, como a convenção de chamada C, tamanhos dos tipos básicos, etc.</para>
|
||||
|
||||
<para>Espera-se que as arquiteturas de Tier 1 sejam totalmente suportadas pelo sistema de ports. Todos os ports devem ser compilados em uma plataforma de Tier 1 ou ter os filtros apropriados para evitar que sejam compilados nas inadequadas. O sistema de empacotamento deve suportar todas as arquiteturas de Tier 1. Para garantir o status de Tier 1 de uma arquitetura, os proponentes dessa arquitetura devem mostrar que todos os pacotes relevantes podem ser compilados nessa plataforma.</para>
|
||||
|
||||
<para>As arquiteturas embarcadas de Tier 1 devem ser capazes de criar pacotes cross-build em pelo menos uma outra arquitetura de Tier 1. Os pacotes devem ser os mais relevantes para a plataforma, mas podem ser um subconjunto não vazio daqueles que são compilados nativamente.</para>
|
||||
|
||||
<para>As arquiteturas de Tier 1 devem ser totalmente documentadas. Todas as operações básicas precisam ser cobertas pelo manual ou por outros documentos. Toda a documentação de integração relevante também deve ser integrada na árvore ou estar prontamente disponível.</para>
|
||||
|
||||
<para>As plataformas atuais Tier 1 são i386 e amd64.</para>
|
||||
<para>Os Tiers são definidos tanto para os kernels quanto para as ABIs do usuário. Normalmente, o kernel de uma plataforma e as ABIs do FreeBSD são atribuídas à mesma Tier.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tier 2: Arquiteturas em Desenvolvimento</title>
|
||||
<title>Tier 1: Arquiteturas Completamente Suportadas</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 Tier 1 são as plataformas mais maduras do FreeBSD. Elas são suportadas pelas equipes de segurança, engenharia de release e gerenciamento de ports. Espera-se que as arquiteturas Tier 1 estejam com Qualidade de Produção em relação a todos os aspectos do sistema operacional FreeBSD, incluindo ambientes de instalação e desenvolvimento.</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>
|
||||
<para>O Projeto FreeBSD fornece as seguintes garantias aos consumidores das plataformas de Tier 1:</para>
|
||||
|
||||
<para>As arquiteturas Tier 2 possuem suporte básico para elas, integradas à infraestrutura de ports. Elas podem ter suporte a cross-build adicionado, a critério do portmgr. Alguns ports devem ser compilados nativamente em pacotes se o sistema de pacotes suportar essa arquitetura. Se não estiver integrado no sistema base, algumas correções externas para a arquitetura dos ports devem ser disponibilizados.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Imagens oficiais de Release do FreeBSD serão fornecidas pela equipe de engenharia de release.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Serão fornecidas atualizações binárias e patches no formato de código fonte para os Avisos de Segurança e Avisos de Erro das versões suportadas.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Serão fornecidos patches de código fonte para os avisos de segurança das branches suportadas.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Atualizações binárias e patches de código fonte geralmente são fornecidos para os avisos de segurança multiplataforma no momento do anúncio.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As alterações nas ABIs do usuário geralmente incluirão bibliotecas de compatibilidade para garantir a operação correta dos binários compilados a partir de qualquer branch estável de uma plataforma Tier 1. Estas bibliotecas podem não ser ativadas na instalação padrão. Se as bibliotecas de compatibilidade não forem fornecidas para uma alteração de ABI, a falta da mesma estará claramente documentada nas notas de versão.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Alterações em certas partes da ABI do kernel incluirão bibliotecas de compatibilidade para garantir a operação correta dos módulos do kernel compilados contra a versão suportada mais antiga da branch. Observe que nem todas as partes da ABI do kernel estão protegidas.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Pacotes binários oficiais para softwares de terceiros serão fornecidos pela equipe de ports. Para arquiteturas embarcadas, esses pacotes podem ser compilados de forma cruzada a partir de uma arquitetura diferente.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Os ports mais relevantes devem ou compilar ou ter filtros apropriados para prevenir a compilação dos inadequados.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Novos recursos que não são inerentemente específicos da plataforma serão totalmente funcionais em todas as arquiteturas de Tier 1.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Os recursos e bibliotecas de compatibilidade usados pelos binários compilados a partir das branchs estáveis mais antigas podem ser removidos nas versões principais mais recentes. Essas remoções serão claramente documentadas nas notas de versão.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas Tier 1 devem ser totalmente documentadas. As operações básicas serão documentadas no Handbook do FreeBSD.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas de Tier 1 serão incluídas na árvore de código fonte.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas de Tier 1 devem ser auto-hospedadas ou por meio de um toolchain disponível na árvore de código fonte ou por meio de um toolchain externo. Se um toolchain externo for necessário, serão fornecidos pacotes binários oficiais para o toolchain externo.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>As arquiteturas Tier 2 podem ser integradas no Handbook do FreeBSD. As noções básicas sobre como obter um sistema em execução devem ser documentadas, embora não necessariamente para cada única placa ou sistema suportado por uma arquitetura Tier 2. A lista de hardware suportada deve existir e ser relativamente recente. Ela deve ser integrado na documentação do FreeBSD.</para>
|
||||
<para>Para manter a maturidade das plataformas de Tier 1, o Projeto FreeBSD manterá os seguintes recursos para apoiar o desenvolvimento:</para>
|
||||
|
||||
<para>As plataformas atuais Tier 2 são arm, arm64, ia64 (através do FreeBSD 10), mips, pc98 (através do FreeBSD 11), powerpc e sparc64.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Suporte à automação do processo de compilação e de testes no cluster FreeBSD.org ou em algum outro local facilmente disponível para todos os desenvolvedores. Plataformas embarcadas podem substituir um emulador disponível no cluster FreeBSD.org por hardware real.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A inclusão nos targets do <userinput>make universe</userinput> e <userinput>make tinderbox</userinput>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Hardware dedicado em um dos clusters do FreeBSD para compilação de pacotes (nativamente ou via qemu-user).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o status de Tier 1 de uma plataforma:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Alterações na árvore de código fonte não devem quebrar conscientemente a compilação de uma plataforma de Tier 1.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As arquiteturas de Tier 1 devem ter um ecossistema maduro e saudável de usuários e desenvolvedores ativos.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Os desenvolvedores devem ser capazes de compilar pacotes em sistemas Tier 1 não-embarcados comumente disponíveis. Isso pode significar compilações nativas se sistemas não-embarcados estiverem normalmente disponíveis para a plataforma em questão, ou significar compilações cruzadas hospedadas em alguma outra arquitetura de Tier 1.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As alterações não podem quebrar a ABI do usuário. Se for necessária uma alteração da ABI, a compatibilidade da ABI com os binários existentes deve ser provida através do versionamento de símbolos ou do versionamento de bibliotecas compartilhadas.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Alterações mescladas em branchs estáveis não podem quebrar as partes protegidas da ABI do kernel. Se for necessária uma alteração da ABI do kernel, ela deverá ser modificada para preservar a funcionalidade dos módulos existentes do kernel.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tier 2: Arquiteturas de Desenvolvimento e Nicho</title>
|
||||
|
||||
<para>As plataformas de Tier 2 são funcionais, mas são plataformas FreeBSD menos maduras. Elas não são suportadas pelas equipes de segurança, engenharia de release e gerenciamento de ports.</para>
|
||||
|
||||
<para>As plataformas Tier 2 podem ser candidatas à plataforma Tier 1 que ainda estão em desenvolvimento ativo. 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>
|
||||
|
||||
<para>O Projeto FreeBSD fornece as seguintes garantias aos consumidores das plataformas de Tier 2:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A infraestrutura de ports deve incluir suporte básico para as arquiteturas de Tier 2 suficiente para suportar a compilação de ports e pacotes. Isso inclui suporte para pacotes básicos, tais como o ports-mgmt/pkg, mas não há garantia de que ports arbitrários serão compiláveis ou funcionais.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Novos recursos que não são inerentemente específicos da plataforma devem ser viáveis em todas as arquiteturas de Tier 2 se não implementados.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas de Tier 2 serão incluídas na árvore de código fonte.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas de Tier 2 devem ser auto-hospedadas ou por meio de um toolchain disponível na árvore de código fonte ou por meio de um toolchain externo. Se um toolchain externo for necessário, serão fornecidos pacotes binários oficiais para o toolchain externo.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As plataformas de Tier 2 devem fornecer kernels e espaço de usuário funcionais, mesmo que uma release oficial não seja provida.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Para manter a maturidade das plataformas de Tier 2, o Projeto FreeBSD manterá os seguintes recursos para apoiar o desenvolvimento:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A inclusão nos targets do <userinput>make universe</userinput> e <userinput>make tinderbox</userinput>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o status de Tier 2 de uma plataforma:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Alterações na árvore de código fonte não devem quebrar conscientemente a compilação de uma plataforma de Tier 2.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>As arquiteturas de Tier 2 devem ter um ecossistema ativo de usuários e desenvolvedores.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Embora sejam permitidas alterações que quebrem a ABI do usuário, a ABI não deve ser quebrada gratuitamente. Alterações significativas da ABI do usuário devem ser restritas às versões principais.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Novos recursos que ainda não foram implementados nas arquiteturas de Tier 2 devem fornecer um meio de desativá-los nessas arquiteturas.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tier 3: Arquiteturas Experimentais</title>
|
||||
|
||||
<para>As plataformas Tier 3 não são suportadas pelo oficial de segurança e nem pelas equipes de engenharia release. A critério dos mantenedores do toolchain, elas podem ser suportados no toolchain. As plataformas Tier 3 são arquiteturas nos estágios iniciais de desenvolvimento, para plataformas de hardware fora do mainstream, ou que são consideradas sistemas legados que provavelmente não serão vistas um uso futuro amplo. O suporte inicial para plataformas Tier 3 é trabalhado em repositórios externos de SCM. A transição para o subversion do FreeBSD ocorre depois que a plataforma inicializa em modo multiusuário em hardware real; o compartilhamento via subversion é necessário para uma exposição mais ampla; e vários desenvolvedores estão trabalhando ativamente na plataforma. As plataformas que fazem a transição para o status de Tier 3 podem ser removidas da árvore se não forem mais suportadas ativamente pela comunidade de desenvolvedores do FreeBSD, a critério do engenheiro de release.</para>
|
||||
<para>As plataformas de Tier 3 têm pelo menos suporte parcial ao FreeBSD. Elas <emphasis>não</emphasis> são suportadas pelas equipes de segurança, engenharia de release e de gerenciamento de ports.</para>
|
||||
|
||||
<para>As plataformas Tier 3 podem ter suporte a ports, integrados ou externos, mas não exigem isso.</para>
|
||||
<para>As plataformas de Tier 3 são arquiteturas nos estágios iniciais de desenvolvimento, para plataformas de hardware não convencionais, ou que são considerados sistemas legados improváveis de serem amplamente utilizados no futuro. O suporte inicial para plataformas de Tier 3 pode existir em um repositório separado em vez do repositório de código fonte principal.</para>
|
||||
|
||||
<para>Plataformas Tier 3 devem ter as noções básicas documentadas de como construir um kernel e como inicializá-lo em pelo menos um ambiente de hardware ou ambiente de emulação alvo. Esta documentação não precisa ser integrada à árvore do FreeBSD.</para>
|
||||
|
||||
<para>As plataformas atuais Tier 3 é a riscv.</para>
|
||||
<para>O Projeto FreeBSD não oferece garantias aos consumidores das plataformas de Tier 3 e não está comprometido em manter recursos para apoiar o seu desenvolvimento. As plataformas de Tier 3 nem sempre podem ser compiláveis, nem quaisquer ABIs do kernel ou de usuário são consideradas estáveis.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tier 4: Arquiteturas Não Suportadas</title>
|
||||
|
||||
<para>Os sistemas Tier 4 não são suportados de nenhuma forma pelo projeto.</para>
|
||||
<para>As plataformas Tier 4 não são suportadas de nenhuma forma pelo projeto.</para>
|
||||
|
||||
<para>Todos os sistemas não classificados em um nível de suporte são sistemas Tier 4. A plataforma ia64 está em transição para o status de Tier 4 no FreeBSD 11. A plataforma pc98 está em transição para o status de Tier 4 no FreeBSD 12.</para>
|
||||
<para>Todos os sistemas não classificados de outra forma são sistemas de Tier 4. Quando uma plataforma faz a transição para o Tier 4, todo o suporte para a plataforma é removido das árvores de código fonte e de ports. Observe que o suporte aos ports deve ser mantido enquanto a plataforma for suportada em uma branch suportada pelo ports.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Política para Alteração do Tier de uma Arquitetura</title>
|
||||
|
||||
<para>Os sistemas só podem ser movidos de uma camada para outra por meio da aprovação do Core Team do FreeBSD, que deve tomar essa decisão em colaboração com as equipes de segurança, engenharia de release e manutenção do toolchain.</para>
|
||||
<para>Os sistemas só podem ser movidos de um Tier para outro por meio da aprovação do Core Team do FreeBSD, que deve tomar essa decisão em colaboração com as equipes de segurança, engenharia de release e gerenciamento dos ports. Para que uma plataforma seja promovida para um Tier superior, todas as garantias de suporte ausentes devem ser atendidas antes que a promoção seja concluída.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -2413,7 +2528,7 @@ Relnotes: yes</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Nenhum outro port contém qualquer referência ao diretório do port ou ao seu PKGNAME em seus Makefiles.</para>
|
||||
<para>Nenhum outro port contém qualquer referência ao diretório do port ou ao seu PKGNAME em seus Makefiles</para>
|
||||
|
||||
<tip>
|
||||
<para>Ao usar o <application>Git</application>, considere o uso do <command>git grep</command>, ele é muito mais rápido que o <command>grep -r</command>.</para>
|
||||
|
|
@ -2573,7 +2688,7 @@ Relnotes: yes</programlisting>
|
|||
</step>
|
||||
|
||||
<step>
|
||||
<para>Faça o commit de todas as alterações de uma única vez</para>
|
||||
<para>Faça o commit de todas as alterações de uma única vez.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</listitem>
|
||||
|
|
@ -2611,7 +2726,7 @@ Relnotes: yes</programlisting>
|
|||
</qandadiv>
|
||||
|
||||
<qandadiv xml:id="ports-qa-freeze">
|
||||
<title>Freeze do Ports </title>
|
||||
<title>Freeze do Ports</title>
|
||||
|
||||
<qandaentry xml:id="ports-qa-freeze-what">
|
||||
<question>
|
||||
|
|
@ -2950,9 +3065,6 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
|
|||
<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>
|
||||
|
||||
|
|
@ -3110,9 +3222,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>
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue