Index: head/pt_BR.ISO8859-1/articles/freebsd-releng/article.xml =================================================================== --- head/pt_BR.ISO8859-1/articles/freebsd-releng/article.xml (revision 53981) +++ head/pt_BR.ISO8859-1/articles/freebsd-releng/article.xml (revision 53982) @@ -1,1026 +1,1026 @@ head/"> stable/"> stable/12/"> releng/"> releng/12.0/"> release/12.0.0/"> 12.0"> ]>
Engenharia de Release do FreeBSD Glen Barber The FreeBSD Foundation Rubicon Communications, LLC (Netgate)
gjb@FreeBSD.org
 FreeBSD is a registered trademark of the FreeBSD Foundation. Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. $FreeBSD$ Este artigo descreve o processo por trás do modelo de engenharia de release adotado pelo Projeto FreeBSD. Introdução ao Processo de Engenharia de Release do FreeBSD O desenvolvimento do FreeBSD segue um fluxo muito específico. Em geral, todas as mudanças no sistema base do FreeBSD são feitas em uma branch chamada head/, a qual reflete o topo da árvore de código fonte. Após um período razoável de testes, as alterações podem ser fundidas na branch stable/. O período de tempo mínimo padrão antes da fusão das alterações na branch stable/ é de três (3) dias. Embora seja uma regra geral esperar pelo menos três (3) dias antes de fundir o código produzido na branch head/, existem algumas circunstâncias especiais em que uma fusão imediata pode ser necessária, tal como uma correção de segurança crítica ou uma correção de bug que inibe diretamente o processo de compilação de uma release. Após vários meses, quando o número de mudanças na branch stable/ cresceu significativamente, é hora de lançar a próxima versão do FreeBSD. Essas versões foram historicamente chamadas de point releases. Entre as versões das branches stable/, aproximadamente a cada dois (2) anos, uma nova versão é criada vinda diretamente da branch head/. Essas versões foram historicamente chamadas de versões dot-zero. Este artigo irá destacar o fluxo de trabalho e as responsabilidades da Equipe de Engenharia de Release do FreeBSD para ambas as versões dot-zero e point release. As seções a seguir deste artigo descrevem: Informações gerais e preparativos antes de iniciar o ciclo de release. Alterações na Página Web Durante o Ciclo de Release Terminologia e informações gerais, como code slush e code freeze, usadas por todo este documento. O processo de Engenharia de Release para uma versão dot-zero. O processo de Engenharia de Release para uma versão point release. Informações relacionadas aos procedimentos específicos para construir o meio de instalação. Procedimentos para publicar um meio de instalação. Encerrando o ciclo de release. Informação Geral e Preparativos Aproximadamente dois meses antes do início do ciclo de vida de uma nova versão, a Equipe de Engenharia de Release do FreeBSD decide sobre um cronograma para o seu lançamento. A programação inclui os vários milestones do ciclo de release, como datas de congelamento, datas para as branches e datas para compilação do código. Por exemplo: Milestone Data prevista pré congelamento da head/: 27 de maio de 2016 Congelamento da head/: 10 de junho de 2016 Congelamento de KBI da head/: 24 de junho de 2016 Pré congelamento da árvore doc/ [1]: 24 de junho de 2016 Branch trimestral dos ports [2]: 1º de julho de 2016 branch stable/12/: 8 de julho de 2016 Aplicação da tag na árvore doc/ [3]: 8 de julho de 2016 Começa a compilação da fase BETA1: 8 de julho de 2016 descongelamento da branch head/: 9 de julho de 2016 Começa a compilação da fase BETA2: 15 de julho de 2016 Começa a compilação da fase BETA3 [*]: 22 de julho de 2016 branch releng/12.0/: 29 de julho de 2016 A compilação da fase RC1 é iniciada: 29 de julho de 2016 descongelamento da branch stable/12/: 30 de julho de 2016 Começa a compilação da fase RC2: 5 de agosto de 2016 Última compilação dos ports [4]: 6 de agosto de 2016 Aplicação da tag na árvore dos ports: 12 de agosto de 2016 compilação da fase RC3 [*]: 12 de agosto de 2016 início de compilação da RELEASE: 19 de agosto de 2016 Anúncio da RELEASE: 2 de setembro de 2016 Itens marcados com "[*]" identificam passos executados apenas "conforme necessário". O pré congelamento da árvore doc é coordenado pela Equipe de Engenharia de Documentação do FreeBSD. A branch trimestral da árvore da coleção de ports é determinada quando a compilação final da fase RC é planejada. Uma nova branch trimestral é criada no primeiro dia do trimestre, portanto, essa métrica deve ser usada ao considerar os marcos do ciclo de release. Uma branch trimestral é criada pela Equipe de Gerenciamento de Ports do FreeBSD. A árvore doc é recebe a tag da Equipe de Engenharia de Documentação do FreeBSD. A compilação final dos pacotes é feita pela Equipe de Gerenciamento de Ports do FreeBSD após a compilação final (ou o que é esperada ser a final) de uma fase RC. Se a versão RELEASE estiver sendo criada a partir de uma branch stable existente, a data de congelamento do KBI poderá ser excluída, já que o KBI já está congelado em branchs stable. Ao escrever o cronograma do ciclo de versões, várias coisas precisam ser levadas em consideração, em particular os milestones nos quais a data alvo depende de milestones pré-definidos sobre os quais existe uma dependência. Por exemplo, a aplicação da tag de release da Coleção de Ports é originada da branch trimestral ativa no momento da última fase do RC. Isso em parte define qual branch trimestral é usada, quando a aplicação da tag pode acontecer e qual revisão da árvore de ports é usada para a construção final de uma RELEASE. Depois de um acordo geral sobre o cronograma, a Equipe de Engenharia de Release do FreeBSD envia e-mails para os desenvolvedores do FreeBSD. É normal que muitos desenvolvedores informem a Equipe de Engenharia de Release do FreeBSD sobre vários trabalhos em andamento. Em alguns casos, uma extensão para o trabalho em andamento será solicitada e, em outros casos, uma solicitação para uma aprovação geral para um subconjunto específico da árvore será feita. Quando tais solicitações são feitas, é importante certificar-se de que os cronogramas (mesmo que estimados) sejam discutidos. Para as aprovações gerais, o período de tempo para a aprovação geral deve ser claro. Por exemplo, um desenvolvedor do FreeBSD pode solicitar aprovações gerais desde o início do code slush até o início da construção da primeira RC. Para manter o controle das aprovações gerais, a Equipe de Engenharia de Release do FreeBSD usa um repositório interno para manter um registro de tais solicitações, que define a área na qual uma aprovação geral foi concedida, o(s) autor(es), quando a aprovação geral expira e a razão pela qual a aprovação foi concedida. Um exemplo disso é a concessão de uma aprovação geral na release/doc/ a todos os membros da Equipe de Engenharia de Release do FreeBSD até o RC final para atualizar as notas de lançamento e outras documentação relacionada ao lançamento. A Equipe de Engenharia de Release do FreeBSD também usa este repositório para rastrear solicitações de aprovação pendentes que são recebidas antes de iniciar várias compilações durante o ciclo de release, que o Engenheiro de Release especifica o período de corte com um email para os desenvolvedores do FreeBSD. Dependendo do conjunto de código subjacente em questão, e do impacto geral que o conjunto de código tem no FreeBSD como um todo, tais solicitações podem ser aprovadas ou negadas pela Equipe de Engenharia de Release do FreeBSD. O mesmo se aplica às extensões de trabalho em andamento. Por exemplo, o trabalho em andamento para um novo driver de dispositivo que de outra forma é isolado do restante da árvore pode receber uma extensão. Um novo scheduler, no entanto, pode não ser viável, especialmente se tais mudanças dramáticas não existirem em outra branch. O cronograma também é adicionado ao site do projeto, no repositório doc, em head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. Este arquivo é continuamente atualizado conforme o ciclo progride. Na maioria dos casos, o schedule.xml pode ser copiado de uma versão anterior e atualizado de acordo. Além de adicionar o schedule.xml ao site, o head/share/xml/navibar.ent e o head/share/xml/release.ent também são atualizados para adicionar o link para o cronograma em várias subpáginas, bem como para habilitar o link para o cronograma na página principal do website do projeto. O cronograma também chamado a partir de head/en_US.ISO8859-1/htdocs/releng/index.xml. Aproximadamente um mês antes do code slush, a Equipe de Engenharia de Release do FreeBSD envia um email de lembrete para os desenvolvedores do FreeBSD. Uma vez que as primeiras compilações do ciclo de release estejam disponíveis, atualize a entidade beta.local.where em head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. substituindo IGNORE por INCLUDE. Se dois ciclos de lançamento paralelo estão acontecendo ao mesmo tempo, a entidade beta2.local.where pode ser usada no lugar. Terminologia da Engenharia de Release Esta seção descreve algumas das terminologias usadas no restante deste documento. O Code Slush Embora o code slush não seja um congelamento mandatório da árvore, a Equipe de Engenharia de Release do FreeBSD solicita que resoluções dos bugs existentes no código tenham prioridade sobre implementação de novos recursos. O code slush não impõe aprovações de confirmação para o Branch. O Code Freeze O code freeze marca o momento em que todos os commits para a branch exigem aprovação explícita da Equipe de Engenharia de Release do FreeBSD. O repositório Subversion do FreeBSD contém vários ganchos para executar verificações de integridade antes que qualquer commit seja realmente confirmado na árvore. Um desses ganchos avaliará se o comprometimento com uma branch específica requer aprovação específica. Para impor aprovações de commit pela Equipe de Engenharia de Release do FreeBSD, o Engenheiro de Release atualiza o base/svnadmin/conf/approvers, e aplica a mudança de volta para o repositório. Feito isso, qualquer alteração na branch deve incluir uma linha Aprovado por: na mensagem de commit. A linha Aprovada por: deve corresponder à segunda coluna em base/svnadmin/conf/aprovovers , caso contrário, o commit será rejeitado pelos hooks do repositório. Durante o code freeze, os committers do FreeBSD devem seguir as Recomendações de Requisição de Mudanças. O <acronym>KBI</acronym> / Congelamento <acronym>KPI</acronym> A estabilidade de KBI/KPI implica que o caller (que faz uma chamada) de uma função através de duas versões diferentes de software que implementam a função, resulta no mesmo estado final. O caller, seja um processo, thread ou função, espera que a função opere de uma determinada maneira, caso contrário, a estabilidade do KBI/KPI na branch é interrompida. Alterações na Página Web Durante o Ciclo de Release Esta seção descreve as alterações no site que devem ocorrer conforme o ciclo de lançamento progride. Os arquivos especificados ao longo desta seção são relativos à branch head/ do repositório doc no Subversion. Alterações na Página Web Antes do Início do Ciclo de Release Quando o cronograma do ciclo de release está disponível, esses arquivos precisam ser atualizados para habilitar várias funcionalidades diferentes no site do Projeto FreeBSD: Arquivo para editar O que mudar share/xml/release.ent Altere beta.upcoming de IGNORE para INCLUDE share/xml/release.ent Altere % beta.upcoming de IGNORE para INCLUDE share/xml/release.ent Altere beta.testing de IGNORE para INCLUDE share/xml/release.ent Altere % beta.testing de IGNORE para INCLUDE Alterações na página web durante a fase <literal>BETA</literal> ou <literal>RC</literal> Ao fazer a transição de PRERELEASE para BETA, esses arquivos precisam ser atualizados para ativar o bloco "Teste de ajuda" na página de download. Todos os arquivos são relativos ao head/ no repositório doc: Arquivo para editar O que mudar en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml Altere % beta.local.where IGNORE para INCLUDE share/xml/release.ent Atualize % betarel.vers para BETA1 share/xml/news.xml Adicione uma entrada anunciando a versão BETA en_US.ISO8859-1/htdocs/security/advisory-template.txt Adicione as novas BETA, RC ou RELEASE final ao modelo en_US.ISO8859-1/htdocs/security/errata-template.txt Adicione as novas BETA, RC ou RELEASE final ao modelo Uma vez criada a branch releng/12.0/, os diversos documentos relacionados à release precisam ser gerados e adicionados manualmente ao repositório doc/. Dentro de release/doc, invoque make1 para gerar as páginas errata.html, hardware.html, readme.html e relnotes.html, que são então adicionadas ao diretório doc/head/en_US.ISO8859-1/htdocs/releases/XYR/, em que XY representa o número da versão principal e da versão secundária. A propriedade fbsd:nokeywords deve ser definido como on nos arquivos recém-adicionados para que os hooks de pré-commit permitam que eles sejam adicionados ao repositório. Os documentos relevantes relacionados à release existem no repositório doc para FreeBSD 12.x e posterior. Mudanças nos ports durante as fases <literal>BETA</literal>, <literal>RC</literal>, e a versão <literal>RELEASE</literal> final Para cada compilação durante o ciclo de release, os arquivos MANIFEST contendo o SHA256 dos vários conjuntos de distribuição, como base.txz, kernel.txz, e assim por diante, são adicionados ao port misc/freebsd-release-manifests. Isso permite outros utilitários além do bsdinstall8, como ports-mgmt/poudriere, usem esses conjuntos de distribuição com segurança fornecendo um mecanismo através do qual os checksums possam ser verificados. Versões oriundas da branch <literal>head/</literal> Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD na branch head. Compilações <quote><literal>ALPHA</literal></quote> do FreeBSD Tendo aparecido primeiramente durante o ciclo de release do FreeBSD 10.0-RELEASE, a noção de compilações de fases ALPHA foi introduzida. Ao contrário das compilações BETA e RC, as compilações desse novo estágio ALPHA não fazem parte do cronograma de Release do FreeBSD. A idéia por trás das compilações ALPHA é disponibilizar builds regulares fornecidas pelo FreeBSD antes da criação da branch stable/. Os snapshots ALPHA do FreeBSD devem ser preparados aproximadamente uma vez por semana. Para a primeira compilação ALPHA, o valor BRANCH em sys/conf/newvers.sh precisa ser alterado de CURRENT para ALPHA1. Para compilações ALPHA subsequentes, incremente cada valor de ALPHAN em um. Veja para informações sobre como construir as imagens ALPHA. Criando a branch <literal>stable/<replaceable>12</replaceable>/</literal> Ao criar a branch stable/, várias alterações são necessárias na nova branch stable/ e na branch head/. Os arquivos listados são relativos ao repositório raiz. Para criar a nova branch stable/12/ no Subversion: % svn cp ^/head stable/12/ Uma vez que a branch stable/12/ tenha sido criada, faça as seguintes edições: Arquivo para editar O que mudar stable/12/UPDATING Atualize a versão do FreeBSD e remova o aviso sobre WITNESS stable/12/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h #ifndef MALLOC_PRODUCTION #define MALLOC_PRODUCTION #endif stable/12/lib/clang/llvm.build.mk Remova o comentário -DNDEBUG stable/12/sys/*/conf/GENERIC* Remova o suporte de depuração stable/12/sys/*/conf/MINIMAL Remova o suporte de depuração stable/12/release/release.conf.sample Atualize o SRCBRANCH stable/12/sys/*/conf/GENERIC-NODEBUG Remova essas configurações do kernel stable/12/sys/arm/conf/std.arm* Remova as opções de depuração stable/12/sys/conf/newvers.sh Atualize o valor de BRANCH para refletir BETA1 stable/12/share/mk/src.opts.mk Mova REPRODUCIBLE_BUILD de __DEFAULT_NO_OPTIONS para __DEFAULT_YES_OPTIONS stable/12/libexec/rc/rc.conf Defina o dumpdev de AUTO para NO (ele é configurável via bsdinstall8 para aqueles que o querem habilitado por padrão) stable/12/release/Makefile Remova as entradas debug.witness.trace Então, na branch head/, que agora se tornará uma nova versão principal: Arquivo para editar O que mudar head/UPDATING Atualize a versão do FreeBSD head/sys/conf/newvers.sh Atualize o valor de BRANCH para refletir CURRENT e incremente a REVISION head/Makefile.inc1 Atualize o TARGET_TRIPLE e o MACHINE_TRIPLE head/sys/sys/param.h Atualize o __FreeBSD_version head/gnu/usr.bin/cc/cc_tools/freebsd-native.h Atualize o FBSD_MAJOR e o FBSD_CC_VER head/contrib/gcc/config.gcc Anexe a seção freebsd<versão>.h head/lib/clang/llvm.build.mk Atualize o valor do OS_VERSION head/release/doc/en_US.ISO8859-1/readme/article.xml Replace &a.current; with &a.stable; ?> head/release/doc/share/xml/release.ent ?> head/lib/clang/freebsd_cc_version.h Atualize o FREEBSD_CC_VERSION head/lib/clang/include/lld/Common/Version.inc Atualize o LLD_REVISION_STRING head/Makefile.libcompat Atualize o LILB32CPUFLAGS Release a partir da branch <literal>stable/</literal> Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD a partir de uma branch stable/. Code Slush da branch <literal>stable</literal> do FreeBSD Na preparação para o code freeze em uma branch stable, vários arquivos precisam ser atualizados para refletir o ciclo de release que está oficialmente em andamento. Esses arquivos são todos relativos ao nível mais alto da branch stable: Arquivo para editar O que mudar sys/conf/newvers.sh Atualize o valor da BRANCH para refletir PRERELEASE Makefile.inc1 Atualize o TARGET_TRIPLE lib/clang/llvm.build.mk Atualize o OS_VERSION Makefile.libcompat Atualize o LILB32CPUFLAGS gnu/usr.bin/groff/tmac/mdoc.local.in Adiciona uma nova entrada .ds para a versão do FreeBSD, e atualiza doc-default-operating-system (FreeBSD 11.x e anteriores apenas) No repositório doc, atualize também head/pt_BR.ISO8859-1/htdocs/releases/12.0R/Makefile.hardware, alternando o valor de _BRANCH para BETAX, RCX ou RELEASE, respectivamente. Builds <literal>BETA</literal> do FreeBSD Após o code slush, a próxima fase do ciclo de release é o code freeze. Este é o ponto no qual todos os commits para a branch stable requerem aprovação explícita da Equipe de Engenharia de Release do FreeBSD. Isto é reforçado por hooks de pré-commit no repositório Subversion editando base/svnadmin/conf/approvers para incluir uma expressão regular que coincida com a branch stable/12/ para a release: ^/stable/12/ re ^/releng/12.0/ re Há duas exceções gerais para exigir aprovação de commit durante o ciclo de release. A primeira é qualquer alteração que precise ser "committed" pelo Engenheiro de Release para continuar com o fluxo de trabalho diário do ciclo de lançamento, e a outra são as correções de segurança que podem ocorrer durante o ciclo de lançamento. Quando o code freeze estiver em vigor, a próxima construção da branch será rotulada como BETA1. Isso é feito atualizando o valor de BRANCH em sys/conf/newvers.sh de PRERELEASE para BETA1. Feito isso, o primeiro conjunto de builds BETA é iniciado. Builds BETA subseqüentes não requerem atualizações em nenhum arquivo diferente do sys/conf/newvers.sh, incrementando o número de compilação da versão BETA. Criando a branch <literal>releng/<replaceable>12.0</replaceable>/</literal> Quando a primeira construção RC (Release Candidate) está pronta para começar, a branch releng/ é criada. Este é um processo de várias etapas que deve ser feito em uma ordem específica, a fim de evitar anomalias, como sobreposições com valores de __ FreeBSD_version, por exemplo. Os caminhos listados abaixo são relativos ao repositório raiz. A ordem dos commits e o que mudar são: % svn cp ^/stable/12/ releng/12.0/ Arquivo para editar O que mudar releng/12.0/sys/conf/newvers.sh Altere BETAX para RC1 releng/12.0/sys/sys/param.h Atualize o __ FreeBSD_version releng/12.0/etc/pkg/FreeBSD.conf Substitua latest por quarterly (trimestral) como a localização padrão do repositório de pacotes releng/12.0/release/pkg_repos/release-dvd.conf Substitua latest por quarterly (trimestral) como a localização padrão do repositório de pacotes stable/12/sys/conf/newvers.sh Atualize BETAX para PRERELEASE stable/12/sys/sys/param.h Atualize o __ FreeBSD_version svnadmin/conf/approvers Adicione uma nova linha de aprovadores para a branch releng como foi feito para a branch stable % svn propdel -R svn:mergeinfo releng/12.0/ % svn commit releng/12.0/ % svn commit stable/12/ Agora que existem dois novos valores de __ FreeBSD_version, também atualize head/pt_BR.ISO8859-1/books/porters-handbook/versions/chapter.xml no repositório do Projeto de Documentação. Depois que a primeira compilação de um RC estiver concluída e testada, a branch stable/ pode ser descongelada removendo (ou comentando) a entrada ^/stable/12/ em svnadmin/conf/approvers. Seguindo a disponibilidade do primeiro RC, o Time Bugmeister do FreeBSD deve ser avisado por e-mail para adicionar o novo FreeBSD -RELEASE às versões disponíveis no menu drop-down exibido no rastreador de bugs. Construindo a Mídia de Instalação do FreeBSD Esta seção descreve os procedimentos gerais de produção de snapshots e releases de desenvolvimento do FreeBSD. Scripts para compilação de Releases Esta seção descreve os scripts de build usados pela Equipe de Engenharia de Release do FreeBSD para produzir snapshots da versão em desenvolvimento e das releases. O script <filename>release.sh</filename> Antes do FreeBSD 9.0-RELEASE, o src/release/Makefile era atualizado para suportar o bsdinstall8, e o script src/release/generate-release.sh foi introduzido como um wrapper para automatizar a chamada dos targets release7. Antes do FreeBSD 9.2-RELEASE, foi introduzido o src/release/release.sh, que baseado fortemente em src/release/generate-release.sh incluía suporte para especificar arquivos de configuração para substituir várias opções e variáveis de ambiente. O suporte para arquivos de configuração forneceu suporte para cross building (compilação para mais de uma arquitetura) de uma release para cada arquitetura, especificando um arquivo de configuração separado para cada chamada. Como um breve exemplo do uso de src/release/release.sh para construir uma única versão em /scratch: # /bin/sh /usr/src/release/release.sh Como um breve exemplo do uso de src/release/release.sh para construir uma única versão cross-build (entre arquiteturas) usando um diretório de destino diferente, crie um release.conf personalizado contendo: # release.sh configuration for powerpc/powerpc64 CHROOTDIR="/scratch-powerpc64" TARGET="powerpc" TARGET_ARCH="powerpc64" KERNEL="GENERIC64" Em seguida, invoque src/release/release.sh da seguinte forma: # /bin/sh /usr/src/release/release.sh -c $HOME/release.conf Veja release7 e src/release/release.conf.sample para mais detalhes e exemplos de uso. O Script Wrapper <filename>thermite.sh</filename> Para tornar o cross building do conjunto completo de arquiteturas suportadas em uma determinada branch mais rápido, mais fácil e reduzindo os fatores de erro humano, um script wrapper de apoio ao src/release/release.sh foi escrito para iterar pelas várias combinações de arquiteturas e chamar o script src/release/release.sh usando um arquivo de configuração específico para essa arquitetura. O script wrapper é chamado de thermite.sh, o qual está disponível no repositório Subversion do FreeBSD em svn://svn.freebsd.org/base/user/gjb/thermite/ , além dos arquivos de configuração usados para construir os snapshots de desenvolvimento head/ e stable/12/. O uso do thermite.sh é explicado em e . Cada arquitetura e kernel individual tem seu próprio arquivo de configuração usado pelo release.sh. Cada branch tem sua própria configuração defaults-X.conf que contém entradas comuns em cada arquitetura, onde substituições ou variáveis especiais são definidas e/ou substituídas nos arquivos por compilação. O esquema de nomenclatura do arquivo de configuração por compilação está na forma de ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, em que as variáveis em maiúsculas são equivalentes a que make1 usa no sistema de compilação e as variáveis minúsculas são definidas nos arquivos de configuração, mapeando para a versão principal da respectiva branch. Cada branch também possui sua própria configuração builds-X.conf, que é usada pelo thermite.sh. O script thermite.sh itera através de cada valor ${revision}, ${TARGET_ARCH}, ${KERNCONF} e ${type}, criando uma lista principal do que construir. No entanto, uma determinada combinação da lista só será criada se o respectivo arquivo de configuração existir, que é onde o esquema de nomenclatura acima é relevante. Existem dois caminhos de fornecimento de arquivos: builds-12.conf -> main.conf Isto controla o comportamento do thermite.sh 12-amd64-GENERIC-snap.conf -> defaults-12.conf -> main.conf Isto controla o comportamento do release/release.sh dentro do chroot8 de compilação Os arquivos de configuração builds-12.conf, defaults-12.conf, e main.conf existem para reduzir a repetição entre os vários arquivos por compilação. Construindo Snapshots de Desenvolvimento do FreeBSD As máquinas oficiais de compilação de versões têm um layout do sistema de arquivos específico, que utiliza ZFS, o thermite.sh tira grande proveito de clones e snapshots, garantindo um ambiente de compilação uniforme e consistente. Os scripts de compilação localizam-se respectivamente em /releng/scripts-snapshot/scripts ou /releng/scripts-release/scripts, para evitar colisões entre uma compilação RC de uma branch releng contra um snapshot STABLE da respectiva branch stable. Existe um dataset (conjunto de dados) separado para as imagens finais de compilação, /snap/ftp. Este diretório contém diretórios de snapshots e releases. Eles são usados apenas se a variável EVERYTHINGISFINE estiver definida em main.conf. O nome da variável EVERYTHINGISFINE foi escolhido para evitar a colisão com uma variável possivelmente definida no ambiente do usuário, ativando acidentalmente o comportamento que depende de sua definição. Como o thermite.sh percorre a lista principal de combinações e localiza o arquivo de configuração por compilação, um dataset ZFS é criado sob o /releng, tal como /releng/12-amd64-GENERIC-snap. O checkout das árvores src/, ports/ e doc/ é realizado em diferentes datasets ZFS, tal como /releng/12-src-snap, os quais são então clonados e montados nos respectivos datasets de compilação. Isso é feito para evitar a remoção de uma determinada árvore mais de uma vez. Assumindo esses caminhos do sistema de arquivos, o thermite.sh deveria ser chamado como: # cd /releng/scripts-snapshot/scripts # ./setrev.sh -b stable/12/ -# ./zfs-setup.sh -c ./builds-12.conf +# ./zfs-cleanup.sh -c ./builds-12.conf # ./thermite.sh -c ./builds-12.conf Quando as compilações forem concluídas, scripts adicionais auxiliares estarão disponíveis para gerar e-mails de snapshots de desenvolvimento que são enviados para a lista de e-mail freebsd-snapshots@freebsd.org: # cd /releng/scripts-snapshot/scripts # ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mail A saída gerada deve ser checada duas vezes para garantir a exatidão, e o próprio e-mail deve ter assinatura PGP, in-line (no arquivo). Esses scripts auxiliares aplicam-se apenas às compilações de snapshot (versão instantânea) de desenvolvimento. Os anúncios durante o ciclo de lançamento (excluindo o anúncio de versão final) são criados a partir de um modelo de email. Uma amostra do modelo de email usado atualmente pode ser encontrada aqui. Construindo Releases do FreeBSD Similar a compilação de snapshots de desenvolvimento do FreeBSD, o thermite.sh seria invocado da mesma maneira. A diferença entre snapshots de desenvolvimento e builds de releases, BETA e RC inclusos, é que os arquivos de configuração do chroot8 devem ser nomeados com release ao invés de snap no "type", como mencionado acima. Além disso, BUILDTYPE e types devem ser alterados de snap para release em defaults-12.conf e builds-12.conf, respectivamente. Ao construir o BETA, o RC, e o RELEASE final, também ajuste estaticamente o BUILDSVNREV para a revisão na branch refletindo a mudança de nome, BUILDDATE para a data em que as compilações são iniciadas no formato YYYYMMDD. Se as árvores doc/ e ports/ tiverem sido marcadas, defina também o PORTBRANCH e o DOCBRANCH para o caminho da tag relevante no repositório Subversion, substituindo HEAD pela última revisão alterada. Também defina releasesrc em builds-12.conf para a branch relevante, como stable/12/ ou releng/12.0/. Durante o ciclo de release, uma cópia do CHECKSUM.SHA512 e do CHECKSUM.SHA256 para cada arquitetura é armazenada no repositório interno da Equipe de Engenharia de Release do FreeBSD, além de ser incluída nos diversos e-mails de anúncio. Cada MANIFEST contendo os hashes do base.txz, do kernel.txz, etc. também são adicionados ao misc/freebsd-release-manifests na coleção de ports. Depois de construir a RELEASE final, a branch releng/12.0/ é marcada como release/12.0.0/ usando a revisão a partir da qual a RELEASE foi construída. Semelhante a criar as branches stable/12/ e releng/12.0/, isso é feito com svn cp. Da raiz do repositório: % svn cp ^/releng/12.0/@r306420 release/12.0.0/ % svn commit release/12.0.0/ Publicando a Mídia de Instalação do FreeBSD nos Espelhos do Projeto Esta seção descreve o procedimento para publicar snapshots e releases de desenvolvimento do FreeBSD nos espelhos do Projeto. Preparando Imagens de Mídias de Instalação do FreeBSD A preparação dos snapshots e das versões do FreeBSD é um processo de duas partes: Criando a estrutura de diretórios para corresponder a hierarquia em ftp-master Se EVERYTHINGISFINE for definido nos arquivos de configuração de compilação, main.conf no caso dos scripts de compilação mencionados acima, isto acontece automaticamente no chroot8 após a compilação ser concluída, criando a estrutura de diretório em ${DESTDIR}/R/ftp-stage com um estrutura de caminho que corresponde ao que é esperado em ftp-master. Isto é equivalente a executar o seguinte diretamente no chroot 8: # make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage Depois que cada arquitetura é compilada, o thermite.sh irá fazer um rsync do ${DESTDIR}/R/ftp-stage da compilação chroot8 para o diretório /snap/ftp/snapshots ou /snap/ftp/releases no host de compilação, respectivamente. Copiando os arquivos para um diretório temporário em ftp-master antes de mover os arquivos para pub/ para iniciar a propagação para os servidores espelhos do Projeto Uma vez que todas as compilações terminarem, /snap/ftp/snapshots, ou /snap/ftp/releases para uma versão, é pesquisado pelo ftp-master usando rsync para /archive/tmp/snapshots ou /archive/tmp/releases, respectivamente. No ftp-master na infraestrutura do Projeto FreeBSD, esta etapa requer acesso ao nível de root, já que esta etapa deve ser executada como o usuário archive. Publicando a Mídia de Instalação do FreeBSD Uma vez que as imagens são colocadas em /archive/tmp/, elas estão prontas para serem publicadas colocando-as em /archive/pub/FreeBSD. Para reduzir o tempo de propagação, o pax1 é usado para criar links físicos a partir de /archive/tmp para /archive/pub/FreeBSD. Para que isto seja efetivo, tanto o /archive/tmp quanto o /archive/pub devem residir no mesmo sistema de arquivos lógico. Há uma ressalva, no entanto, em que o rsync deve ser usado após o pax1 para corrigir os links simbólicos no pub/FreeBSD/snapshots/ISO-IMAGES que o pax1 irá substituir por um hard link, aumentando o tempo de propagação. Assim como nas etapas de preparação, isto requer acesso em nível de root, já que essa etapa deve ser executada como o usuário archive. Como o usuário archive: % cd /archive/tmp/snapshots % pax -r -w -l . /archive/pub/FreeBSD/snapshots % /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/ Substitua os snapshots por releases conforme apropriado. Encerrando o Ciclo de Release Esta seção descreve as tarefas gerais de pós-release. Avisos de Erratas de Pós-Release A medida que o ciclo de release se aproxima da conclusão, é comum ter vários candidatos a EN (Aviso de Erratas) para abordar os problemas que foram descobertos ao final do ciclo. Após o lançamento, a Equipe de Engenharia de Release do FreeBSD e a Equipe de Segurança do FreeBSD reveem mudanças que não foram aprovadas antes da versão final, e dependendo do escopo da mudança em questão, podem emitir um EN. O processo atual de emissão de ENs é tratado pela Equipe de Segurança do FreeBSD. Para solicitar uma Errata após a conclusão de um ciclo de lançamento, o desenvolvedor deve preencher o Template de Errata>, em particular as seções Background, Problem Description, Impact e, se aplicável, as seções Workaround. O modelo de Errata preenchido deve ser enviado por e-mail juntamente com um patch na branch releng/ ou uma lista de revisões da branch stable/. Para pedidos de Errata imediatamente após o lançamento, o pedido deve ser enviado por e-mail à Equipe de Engenharia de Releases do FreeBSD e à Equipe de Segurança do FreeBSD. Depois que a branch releng/ foi entregue à equipe de Segurança do FreeBSD, conforme descrito em , as solicitações de Errata devem ser enviadas à equipe de Segurança do FreeBSD. Entrega para a Equipe de Segurança do FreeBSD Aproximadamente duas semanas após o lançamento, o Engenheiro de Release atualiza o svnadmin/conf/approvers alterando a coluna do aprovador de re para (so|security-officer) para a branch releng/12.0/.
Index: head/pt_BR.ISO8859-1/articles/freebsd-releng/pt_BR.po =================================================================== --- head/pt_BR.ISO8859-1/articles/freebsd-releng/pt_BR.po (revision 53981) +++ head/pt_BR.ISO8859-1/articles/freebsd-releng/pt_BR.po (revision 53982) @@ -1,2735 +1,2735 @@ # $FreeBSD$ -# Danilo G. Baio , 2019. #zanata +# Danilo G. Baio , 2019. #zanata, 2020. # Edson Brandi , 2019. #zanata msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2019-11-16 16:30-0300\n" -"PO-Revision-Date: 2019-11-16 19:02+0000\n" +"POT-Creation-Date: 2020-03-14 17:16-0300\n" +"PO-Revision-Date: 2020-03-14 20:09+0000\n" "Last-Translator: Danilo G. Baio \n" -"Language-Team: Portuguese (Brazil) \n" +"Language-Team: Portuguese (Brazil) \n" "Language: pt_BR\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" -"X-Generator: Weblate 3.9.1\n" +"X-Generator: Weblate 3.11.2\n" #. Put one translator per line, in the form NAME , YEAR1, YEAR2 msgctxt "_" msgid "translator-credits" msgstr "" "Edson Brandi, ebrandi@FreeBSD.org, 2018\n" "Lucas Andrade, slucasandrade@protonmail.ch, 2018\n" "André Franciosi, andre@franciosi.org, 2018\n" "Vinícius Zavam, egypcio@googlemail.com, 2018\n" "Silvio Ap Silva, contato@kanazuchi.com, 2018" #. (itstool) path: info/title #: article.translate.xml:26 msgid "FreeBSD Release Engineering" msgstr "Engenharia de Release do FreeBSD" #. (itstool) path: affiliation/address #: article.translate.xml:41 #, no-wrap msgid "gjb@FreeBSD.org" msgstr "gjb@FreeBSD.org" #. (itstool) path: authorgroup/author #: article.translate.xml:29 msgid "" " Glen Barber The FreeBSD Foundation Rubicon Communications, LLC (Netgate) <_:" "address-1/> " msgstr "" " Glen Barber The FreeBSD Foundation Rubicon Communications, LLC (Netgate) <_:" "address-1/> " #. (itstool) path: legalnotice/para #: article.translate.xml:47 msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." #. (itstool) path: legalnotice/para #: article.translate.xml:49 msgid "" "Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " "and Xeon are trademarks or registered trademarks of Intel Corporation or its " "subsidiaries in the United States and other countries." msgstr "" "Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " "and Xeon are trademarks or registered trademarks of Intel Corporation or its " "subsidiaries in the United States and other countries." #. (itstool) path: legalnotice/para #: article.translate.xml:53 msgid "" "Many of the designations used by manufacturers and sellers to distinguish " "their products are claimed as trademarks. Where those designations appear in " "this document, and the FreeBSD Project was aware of the trademark claim, the " "designations have been followed by the ™ or the ® symbol." msgstr "" "Many of the designations used by manufacturers and sellers to distinguish " "their products are claimed as trademarks. Where those designations appear in " "this document, and the FreeBSD Project was aware of the trademark claim, the " "designations have been followed by the ™ or the ® symbol." #. (itstool) path: info/pubdate #: article.translate.xml:61 msgid "" "$FreeBSD: head/en_US.ISO8859-1/articles/freebsd-releng/article.xml 53242 " "2019-07-09 23:59:30Z jhb $" msgstr "" "$FreeBSD: head/en_US.ISO8859-1/articles/freebsd-releng/article.xml 53242 " "2019-07-09 23:59:30Z jhb $" #. (itstool) path: abstract/para #: article.translate.xml:64 msgid "" "This article describes the release engineering process of the " "FreeBSD Project." msgstr "" "Este artigo descreve o processo por trás do modelo de engenharia de release " "adotado pelo Projeto FreeBSD." #. (itstool) path: sect1/title #: article.translate.xml:70 msgid "Introduction to the FreeBSD Release Engineering Process" msgstr "Introdução ao Processo de Engenharia de Release do FreeBSD" #. (itstool) path: sect1/para #: article.translate.xml:73 msgid "" "Development of FreeBSD has a very specific workflow. In general, all changes " "to the FreeBSD base system are committed to the head/ " "branch, which reflects the top of the source tree." msgstr "" "O desenvolvimento do FreeBSD segue um fluxo muito específico. Em geral, " "todas as mudanças no sistema base do FreeBSD são feitas em uma branch " "chamada head/, a qual reflete o topo da árvore de código " "fonte." #. (itstool) path: sect1/para #: article.translate.xml:78 msgid "" "After a reasonable testing period, changes can then be merged to the " "stable/ branches. The default minimum timeframe before " "merging to stable/ branches is three (3) days." msgstr "" "Após um período razoável de testes, as alterações podem ser fundidas na " "branch stable/. O período de tempo mínimo padrão antes da " "fusão das alterações na branch stable/ é de três (3) dias." #. (itstool) path: sect1/para #: article.translate.xml:83 msgid "" "Although a general rule to wait a minimum of three days before merging from " "head/, there are a few special circumstances where an " "immediate merge may be necessary, such as a critical security fix, or a bug " "fix that directly inhibits the release build process." msgstr "" "Embora seja uma regra geral esperar pelo menos três (3) dias antes de fundir " "o código produzido na branch head/, existem algumas " "circunstâncias especiais em que uma fusão imediata pode ser necessária, tal " "como uma correção de segurança crítica ou uma correção de bug que inibe " "diretamente o processo de compilação de uma release." #. (itstool) path: sect1/para #: article.translate.xml:89 msgid "" "After several months, and the number of changes in the stable/ branch have grown significantly, it is time to release the next " "version of FreeBSD. These releases have been historically referred to as " "point releases." msgstr "" "Após vários meses, quando o número de mudanças na branch stable/ cresceu significativamente, é hora de lançar a próxima versão do " "FreeBSD. Essas versões foram historicamente chamadas de point " "releases." #. (itstool) path: sect1/para #: article.translate.xml:95 msgid "" "In between releases from the stable/ branches, " "approximately every two (2) years, a release will be cut directly from " "head/. These releases have been historically referred to " "as dot-zero releases." msgstr "" "Entre as versões das branches stable/, aproximadamente a " "cada dois (2) anos, uma nova versão é criada vinda diretamente da branch " "head/. Essas versões foram historicamente chamadas de " "versões dot-zero." #. (itstool) path: sect1/para #: article.translate.xml:101 msgid "" "This article will highlight the workflow and responsibilities of the FreeBSD " "Release Engineering Team for both dot-zero and point' releases." msgstr "" "Este artigo irá destacar o fluxo de trabalho e as responsabilidades da " "Equipe de Engenharia de Release do FreeBSD para ambas as versões dot-" "zero e point release." #. (itstool) path: sect1/para #: article.translate.xml:106 msgid "The following sections of this article describe:" msgstr "As seções a seguir deste artigo descrevem:" #. (itstool) path: listitem/para #: article.translate.xml:113 msgid "General information and preparation before starting the release cycle." msgstr "Informações gerais e preparativos antes de iniciar o ciclo de release." #. (itstool) path: listitem/para #. (itstool) path: sect1/title #: article.translate.xml:122 article.translate.xml:512 msgid "Website Changes During the Release Cycle" msgstr "Alterações na Página Web Durante o Ciclo de Release" #. (itstool) path: listitem/para #: article.translate.xml:130 msgid "" "Terminology and general information, such as the code slush " "and code freeze, used throughout this document." msgstr "" "Terminologia e informações gerais, como code slush e " "code freeze, usadas por todo este documento." #. (itstool) path: listitem/para #: article.translate.xml:140 msgid "The Release Engineering process for a dot-zero release." msgstr "" "O processo de Engenharia de Release para uma versão dot-zero." #. (itstool) path: listitem/para #: article.translate.xml:149 msgid "The Release Engineering process for a point release." msgstr "" "O processo de Engenharia de Release para uma versão point release." #. (itstool) path: listitem/para #: article.translate.xml:158 msgid "" "Information related to the specific procedures to build installation medium." msgstr "" "Informações relacionadas aos procedimentos específicos para construir o meio " "de instalação." #. (itstool) path: listitem/para #: article.translate.xml:167 msgid "Procedures to publish installation medium." msgstr "Procedimentos para publicar um meio de instalação." #. (itstool) path: listitem/para #: article.translate.xml:175 msgid "Wrapping up the release cycle." msgstr "Encerrando o ciclo de release." #. (itstool) path: sect1/title #: article.translate.xml:182 msgid "General Information and Preparation" msgstr "Informação Geral e Preparativos" #. (itstool) path: sect1/para #: article.translate.xml:184 msgid "" "Approximately two months before the start of the release cycle, the FreeBSD " "Release Engineering Team decides on a schedule for the release. The schedule " "includes the various milestone points of the release cycle, such as freeze " "dates, branch dates, and build dates. For example:" msgstr "" "Aproximadamente dois meses antes do início do ciclo de vida de uma nova " "versão, a Equipe de Engenharia de Release do FreeBSD decide sobre um " "cronograma para o seu lançamento. A programação inclui os vários milestones " "do ciclo de release, como datas de congelamento, datas para as branches e " "datas para compilação do código. Por exemplo:" #. (itstool) path: row/entry #: article.translate.xml:194 msgid "Milestone" msgstr "Milestone" #. (itstool) path: row/entry #: article.translate.xml:195 msgid "Anticipated Date" msgstr "Data prevista" #. (itstool) path: row/entry #: article.translate.xml:201 msgid "head/ slush:" msgstr "pré congelamento da head/:" #. (itstool) path: row/entry #: article.translate.xml:202 msgid "May 27, 2016" msgstr "27 de maio de 2016" #. (itstool) path: row/entry #: article.translate.xml:206 msgid "head/ freeze:" msgstr "Congelamento da head/:" #. (itstool) path: row/entry #: article.translate.xml:207 msgid "June 10, 2016" msgstr "10 de junho de 2016" #. (itstool) path: row/entry #: article.translate.xml:211 msgid "head/ KBI freeze:" msgstr "Congelamento de KBI da head/:" #. (itstool) path: row/entry #: article.translate.xml:212 article.translate.xml:217 msgid "June 24, 2016" msgstr "24 de junho de 2016" #. (itstool) path: row/entry #: article.translate.xml:216 msgid "doc/ tree slush [1]:" msgstr "Pré congelamento da árvore doc/ [1]:" #. (itstool) path: row/entry #: article.translate.xml:221 msgid "Ports quarterly branch [2]:" msgstr "Branch trimestral dos ports [2]:" #. (itstool) path: row/entry #: article.translate.xml:222 msgid "July 1, 2016" msgstr "1º de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:226 msgid "stable/12/ branch:" msgstr "branch stable/12/:" #. (itstool) path: row/entry #: article.translate.xml:227 article.translate.xml:232 #: article.translate.xml:237 msgid "July 8, 2016" msgstr "8 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:231 msgid "doc/ tree tag [3]:" msgstr "Aplicação da tag na árvore doc/ [3]:" #. (itstool) path: row/entry #: article.translate.xml:236 msgid "BETA1 build starts:" msgstr "Começa a compilação da fase BETA1:" #. (itstool) path: row/entry #: article.translate.xml:241 msgid "head/ thaw:" msgstr "descongelamento da branch head/:" #. (itstool) path: row/entry #: article.translate.xml:242 msgid "July 9, 2016" msgstr "9 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:246 msgid "BETA2 build starts:" msgstr "Começa a compilação da fase BETA2:" #. (itstool) path: row/entry #: article.translate.xml:247 msgid "July 15, 2016" msgstr "15 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:251 msgid "BETA3 build starts [*]:" msgstr "Começa a compilação da fase BETA3 [*]:" #. (itstool) path: row/entry #: article.translate.xml:252 msgid "July 22, 2016" msgstr "22 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:256 msgid "releng/12.0/ branch:" msgstr "branch releng/12.0/:" #. (itstool) path: row/entry #: article.translate.xml:257 article.translate.xml:262 msgid "July 29, 2016" msgstr "29 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:261 msgid "RC1 build starts:" msgstr "A compilação da fase RC1 é iniciada:" #. (itstool) path: row/entry #: article.translate.xml:266 msgid "stable/12/ thaw:" msgstr "" "descongelamento da branch stable/12/:" #. (itstool) path: row/entry #: article.translate.xml:267 msgid "July 30, 2016" msgstr "30 de julho de 2016" #. (itstool) path: row/entry #: article.translate.xml:271 msgid "RC2 build starts:" msgstr "Começa a compilação da fase RC2:" #. (itstool) path: row/entry #: article.translate.xml:272 msgid "August 5, 2016" msgstr "5 de agosto de 2016" #. (itstool) path: row/entry #: article.translate.xml:276 msgid "Final Ports package builds [4]:" msgstr "Última compilação dos ports [4]:" #. (itstool) path: row/entry #: article.translate.xml:277 msgid "August 6, 2016" msgstr "6 de agosto de 2016" #. (itstool) path: row/entry #: article.translate.xml:281 msgid "Ports release tag:" msgstr "Aplicação da tag na árvore dos ports:" #. (itstool) path: row/entry #: article.translate.xml:282 article.translate.xml:287 msgid "August 12, 2016" msgstr "12 de agosto de 2016" #. (itstool) path: row/entry #: article.translate.xml:286 msgid "RC3 build starts [*]:" msgstr "compilação da fase RC3 [*]:" #. (itstool) path: row/entry #: article.translate.xml:291 msgid "RELEASE build starts:" msgstr "início de compilação da RELEASE:" #. (itstool) path: row/entry #: article.translate.xml:292 msgid "August 19, 2016" msgstr "19 de agosto de 2016" #. (itstool) path: row/entry #: article.translate.xml:296 msgid "RELEASE announcement:" msgstr "Anúncio da RELEASE:" #. (itstool) path: row/entry #: article.translate.xml:297 msgid "September 2, 2016" msgstr "2 de setembro de 2016" #. (itstool) path: note/para #: article.translate.xml:304 msgid "Items marked with \"[*]\" are \"as needed\"." msgstr "" "Itens marcados com \"[*]\" identificam passos executados apenas \"conforme " "necessário\"." #. (itstool) path: listitem/para #: article.translate.xml:310 msgid "" "The doc/ tree slush is coordinated by the FreeBSD " "Documentation Engineering Team." msgstr "" "O pré congelamento da árvore doc é coordenado pela Equipe " "de Engenharia de Documentação do FreeBSD." #. (itstool) path: listitem/para #: article.translate.xml:315 msgid "" "The Ports quarterly branch used is determined by when the final RC build is planned. A new quarterly branch is created on the first " "day of the quarter, so this metric should be used when taking the release " "cycle milestones into account. The quarterly branch is created by the " "FreeBSD Ports Management Team." msgstr "" "A branch trimestral da árvore da coleção de ports é determinada quando a " "compilação final da fase RC é planejada. Uma nova branch " "trimestral é criada no primeiro dia do trimestre, portanto, essa métrica " "deve ser usada ao considerar os marcos do ciclo de release. Uma branch " "trimestral é criada pela Equipe de Gerenciamento de Ports do FreeBSD." #. (itstool) path: listitem/para #: article.translate.xml:324 msgid "" "The doc/ tree is tagged by the FreeBSD Documentation " "Engineering Team." msgstr "" "A árvore doc é recebe a tag da Equipe de Engenharia de " "Documentação do FreeBSD." #. (itstool) path: listitem/para #: article.translate.xml:329 msgid "" "The final Ports package build is done by the FreeBSD Ports Management Team " "after the final (or what is expected to be final) RC " "build." msgstr "" "A compilação final dos pacotes é feita pela Equipe de Gerenciamento de Ports " "do FreeBSD após a compilação final (ou o que é esperada ser a final) de uma " "fase RC." #. (itstool) path: note/para #: article.translate.xml:336 msgid "" "If the release is being created from an existing stable/ " "branch, the KBI freeze date can be excluded, since the " "KBI is already considered frozen on established " "stable/ branches." msgstr "" "Se a versão RELEASE estiver sendo criada a partir de uma branch " "stable existente, a data de congelamento do KBI poderá ser excluída, já que o KBI já está " "congelado em branchs stable." #. (itstool) path: sect1/para #: article.translate.xml:343 msgid "" "When writing the release cycle schedule, a number of things need to be taken " "into consideration, in particular milestones where the target date depends " "on predefined milestones upon which there is a dependency. For example, the " "Ports Collection release tag originates from the active quarterly branch at " "the time of the last RC. This in part defines which " "quarterly branch is used, when the release tag can happen, and what revision " "of the ports tree is used for the final RELEASE build." msgstr "" "Ao escrever o cronograma do ciclo de versões, várias coisas precisam ser " "levadas em consideração, em particular os milestones nos quais a data alvo " "depende de milestones pré-definidos sobre os quais existe uma dependência. " "Por exemplo, a aplicação da tag de release da Coleção de Ports é originada " "da branch trimestral ativa no momento da última fase do RC. Isso em parte define qual branch trimestral é usada, quando a " "aplicação da tag pode acontecer e qual revisão da árvore de ports é usada " "para a construção final de uma RELEASE." #. (itstool) path: sect1/para #: article.translate.xml:353 msgid "" "After general agreement on the schedule, the FreeBSD Release Engineering " "Team emails the schedule to the FreeBSD Developers." msgstr "" "Depois de um acordo geral sobre o cronograma, a Equipe de Engenharia de " "Release do FreeBSD envia e-mails para os desenvolvedores do FreeBSD." #. (itstool) path: sect1/para #: article.translate.xml:356 msgid "" "It is somewhat typical that many developers will inform the FreeBSD Release " "Engineering Team about various works-in-progress. In some cases, an " "extension for the in-progress work will be requested, and in other cases, a " "request for blanket approval to a particular subset of the " "tree will be made." msgstr "" "É normal que muitos desenvolvedores informem a Equipe de Engenharia de " "Release do FreeBSD sobre vários trabalhos em andamento. Em alguns casos, uma " "extensão para o trabalho em andamento será solicitada e, em outros casos, " "uma solicitação para uma aprovação geral para um subconjunto " "específico da árvore será feita." #. (itstool) path: sect1/para #: article.translate.xml:362 msgid "" "When such requests are made, it is important to make sure timelines (even if " "estimated) are discussed. For blanket approvals, the length of time for the " "blanket approval should be made clear. For example, a FreeBSD developer may " "request blanket approvals from the start of the code slush until the start " "of the RC builds." msgstr "" "Quando tais solicitações são feitas, é importante certificar-se de que os " "cronogramas (mesmo que estimados) sejam discutidos. Para as aprovações " "gerais, o período de tempo para a aprovação geral deve ser claro. Por " "exemplo, um desenvolvedor do FreeBSD pode solicitar aprovações gerais desde " "o início do code slush até o início da construção da primeira RC." #. (itstool) path: note/para #: article.translate.xml:370 msgid "" "In order to keep track of blanket approvals, the FreeBSD Release Engineering " "Team uses an internal repository to keep a running log of such requests, " "which defines the area upon which a blanket approval was granted, the " "author(s), when the blanket approval expires, and the reason the approval " "was granted. One example of this is granting blanket approval to release/doc/ to all FreeBSD Release " "Engineering Team members until the final RC to update the " "release notes and other release-related documentation." msgstr "" "Para manter o controle das aprovações gerais, a Equipe de Engenharia de " "Release do FreeBSD usa um repositório interno para manter um registro de " "tais solicitações, que define a área na qual uma aprovação geral foi " "concedida, o(s) autor(es), quando a aprovação geral expira e a razão pela " "qual a aprovação foi concedida. Um exemplo disso é a concessão de uma " "aprovação geral na release/doc/ a " "todos os membros da Equipe de Engenharia de Release do FreeBSD até o " "RC final para atualizar as notas de lançamento e outras " "documentação relacionada ao lançamento." #. (itstool) path: note/para #: article.translate.xml:381 msgid "" "The FreeBSD Release Engineering Team also uses this repository to track " "pending approval requests that are received just prior to starting various " "builds during the release cycle, which the Release Engineer specifies the " "cutoff period with an email to the FreeBSD developers." msgstr "" "A Equipe de Engenharia de Release do FreeBSD também usa este repositório " "para rastrear solicitações de aprovação pendentes que são recebidas antes de " "iniciar várias compilações durante o ciclo de release, que o Engenheiro de " "Release especifica o período de corte com um email para os desenvolvedores " "do FreeBSD." #. (itstool) path: sect1/para #: article.translate.xml:388 msgid "" "Depending on the underlying set of code in question, and the overall impact " "the set of code has on FreeBSD as a whole, such requests may be approved or " "denied by the FreeBSD Release Engineering Team." msgstr "" "Dependendo do conjunto de código subjacente em questão, e do impacto geral " "que o conjunto de código tem no FreeBSD como um todo, tais solicitações " "podem ser aprovadas ou negadas pela Equipe de Engenharia de Release do " "FreeBSD." #. (itstool) path: sect1/para #: article.translate.xml:392 msgid "" "The same applies to work-in-progress extensions. For example, in-progress " "work for a new device driver that is otherwise isolated from the rest of the " "tree may be granted an extension. A new scheduler, however, may not be " "feasible, especially if such dramatic changes do not exist in another branch." msgstr "" "O mesmo se aplica às extensões de trabalho em andamento. Por exemplo, o " "trabalho em andamento para um novo driver de dispositivo que de outra forma " "é isolado do restante da árvore pode receber uma extensão. Um novo " "scheduler, no entanto, pode não ser viável, especialmente se tais mudanças " "dramáticas não existirem em outra branch." #. (itstool) path: sect1/para #: article.translate.xml:399 msgid "" "The schedule is also added to the Project website, in the doc/ repository, in head/en_US.ISO8859-1/htdocs/releases/" "12.0R/schedule.xml. This file is " "continuously updated as the release cycle progresses." msgstr "" "O cronograma também é adicionado ao site do projeto, no repositório " "doc, em head/en_US.ISO8859-1/htdocs/releases/" "12.0R/schedule.xml. Este arquivo é " "continuamente atualizado conforme o ciclo progride." #. (itstool) path: note/para #: article.translate.xml:406 msgid "" "In most cases, the schedule.xml can be copied from a " "prior release and updated accordingly." msgstr "" "Na maioria dos casos, o schedule.xml pode ser copiado " "de uma versão anterior e atualizado de acordo." #. (itstool) path: sect1/para #: article.translate.xml:410 msgid "" "In addition to adding schedule.xml to the website, " "head/share/xml/navibar.ent and head/share/xml/" "release.ent are also updated to add the link to the schedule to " "various subpages, as well as enabling the link to the schedule on the " "Project website index page." msgstr "" "Além de adicionar o schedule.xml ao site, o " "head/share/xml/navibar.ent e o head/share/xml/" "release.ent também são atualizados para adicionar o link para o " "cronograma em várias subpáginas, bem como para habilitar o link para o " "cronograma na página principal do website do projeto." #. (itstool) path: sect1/para #: article.translate.xml:417 msgid "" "The schedule is also linked from head/en_US.ISO8859-1/htdocs/" "releng/index.xml." msgstr "" "O cronograma também chamado a partir de head/en_US.ISO8859-1/" "htdocs/releng/index.xml." #. (itstool) path: sect1/para #: article.translate.xml:420 msgid "" "Approximately one month prior to the scheduled code slush, " "the FreeBSD Release Engineering Team sends a reminder email to the FreeBSD " "Developers." msgstr "" "Aproximadamente um mês antes do code slush, a Equipe de " "Engenharia de Release do FreeBSD envia um email de lembrete para os " "desenvolvedores do FreeBSD." #. (itstool) path: sect1/para #: article.translate.xml:424 msgid "" "Once the first builds of the release cycle are available, update the " "beta.local.where entity in head/en_US.ISO8859-1/" "htdocs/releases/12.0R/schedule.xml. " "replacing IGNORE with INCLUDE." msgstr "" "Uma vez que as primeiras compilações do ciclo de release estejam " "disponíveis, atualize a entidade beta.local.where em " "head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. substituindo IGNORE por INCLUDE." #. (itstool) path: note/para #: article.translate.xml:431 msgid "" "If two parallel release cycles are happening at once, the beta2." "local.where entity may be used instead." msgstr "" "Se dois ciclos de lançamento paralelo estão acontecendo ao mesmo tempo, a " "entidade beta2.local.where pode ser usada no lugar." #. (itstool) path: sect1/title #: article.translate.xml:444 msgid "Release Engineering Terminology" msgstr "Terminologia da Engenharia de Release" #. (itstool) path: sect1/para #: article.translate.xml:446 msgid "" "This section describes some of the terminology used throughout the rest of " "this document." msgstr "" "Esta seção descreve algumas das terminologias usadas no restante deste " "documento." #. (itstool) path: sect2/title #: article.translate.xml:450 msgid "The Code Slush" msgstr "O Code Slush" #. (itstool) path: sect2/para #: article.translate.xml:452 msgid "" "Although the code slush is not a hard freeze on the tree, the FreeBSD " "Release Engineering Team requests that bugs in the existing code base take " "priority over new features." msgstr "" "Embora o code slush não seja um congelamento mandatório da árvore, a Equipe " "de Engenharia de Release do FreeBSD solicita que resoluções dos bugs " "existentes no código tenham prioridade sobre implementação de novos recursos." #. (itstool) path: sect2/para #: article.translate.xml:456 msgid "The code slush does not enforce commit approvals to the branch." msgstr "O code slush não impõe aprovações de confirmação para o Branch." #. (itstool) path: sect2/title #: article.translate.xml:461 msgid "The Code Freeze" msgstr "O Code Freeze" #. (itstool) path: sect2/para #: article.translate.xml:463 msgid "" "The code freeze marks the point in time where all commits to the branch " "require explicit approval from the FreeBSD Release Engineering Team." msgstr "" "O code freeze marca o momento em que todos os commits para a branch exigem " "aprovação explícita da Equipe de Engenharia de Release do FreeBSD." #. (itstool) path: sect2/para #: article.translate.xml:466 msgid "" "The FreeBSD Subversion repository contains " "several hooks to perform sanity checks before any commit is actually " "committed to the tree. One of these hooks will evaluate if committing to a " "particular branch requires specific approval." msgstr "" "O repositório Subversion do FreeBSD contém vários " "ganchos para executar verificações de integridade antes que qualquer commit " "seja realmente confirmado na árvore. Um desses ganchos avaliará se o " "comprometimento com uma branch específica requer aprovação específica." #. (itstool) path: sect2/para #: article.translate.xml:472 msgid "" "To enforce commit approvals by the FreeBSD Release Engineering Team, the " "Release Engineer updates base/svnadmin/conf/approvers, " "and commits the change back to the repository. Once this is done, any change " "to the branch must include an Approved by: line in the commit " "message." msgstr "" "Para impor aprovações de commit pela Equipe de Engenharia de Release do " "FreeBSD, o Engenheiro de Release atualiza o base/svnadmin/conf/" "approvers, e aplica a mudança de volta para o repositório. Feito " "isso, qualquer alteração na branch deve incluir uma linha Aprovado " "por: na mensagem de commit." #. (itstool) path: sect2/para #: article.translate.xml:479 msgid "" "The Approved by: line must match the second column in " "base/svnadmin/conf/approvers, otherwise the commit will " "be rejected by the repository hooks." msgstr "" "A linha Aprovada por: deve corresponder à segunda coluna em " "base/svnadmin/conf/aprovovers , caso contrário, o " "commit será rejeitado pelos hooks do repositório." #. (itstool) path: note/para #: article.translate.xml:485 msgid "" "During the code freeze, FreeBSD committers are urged to follow the Change Request Guidelines." msgstr "" "Durante o code freeze, os committers do FreeBSD devem seguir as Recomendações de Requisição de Mudanças." #. (itstool) path: sect2/title #: article.translate.xml:492 msgid "The KBI/KPI Freeze" msgstr "O KBI / Congelamento KPI" #. (itstool) path: sect2/para #: article.translate.xml:495 msgid "" "KBI/KPI stability implies that the " "caller of a function across two different releases of software that " "implement the function results in the same end state. The caller, whether it " "is a process, thread, or function, expects the function to operate in a " "certain way, otherwise the KBI/KPI " "stability on the branch is broken." msgstr "" "A estabilidade de KBI/KPI implica que " "o caller (que faz uma chamada) de uma função através de duas versões " "diferentes de software que implementam a função, resulta no mesmo estado " "final. O caller, seja um processo, thread ou função, espera que a função " "opere de uma determinada maneira, caso contrário, a estabilidade do " "KBI/KPI na branch é interrompida." #. (itstool) path: sect1/para #: article.translate.xml:514 msgid "" "This section describes the changes to the website that should occur as the " "release cycle progresses." msgstr "" "Esta seção descreve as alterações no site que devem ocorrer conforme o ciclo " "de lançamento progride." #. (itstool) path: note/para #: article.translate.xml:518 msgid "" "The files specified throughout this section are relative to the " "head/ branch of the doc repository in " "Subversion." msgstr "" "Os arquivos especificados ao longo desta seção são relativos à branch " "head/ do repositório doc no " "Subversion." #. (itstool) path: sect2/title #: article.translate.xml:525 msgid "Website Changes Before the Release Cycle Begins" msgstr "Alterações na Página Web Antes do Início do Ciclo de Release" #. (itstool) path: sect2/para #: article.translate.xml:527 msgid "" "When the release cycle schedule is available, these files need to be updated " "to enable various different functionalities on the FreeBSD Project website:" msgstr "" "Quando o cronograma do ciclo de release está disponível, esses arquivos " "precisam ser atualizados para habilitar várias funcionalidades diferentes no " "site do Projeto FreeBSD:" #. (itstool) path: row/entry #: article.translate.xml:535 article.translate.xml:587 #: article.translate.xml:732 article.translate.xml:818 #: article.translate.xml:927 article.translate.xml:1029 msgid "File to Edit" msgstr "Arquivo para editar" #. (itstool) path: row/entry #: article.translate.xml:536 article.translate.xml:588 #: article.translate.xml:733 article.translate.xml:819 #: article.translate.xml:928 article.translate.xml:1030 msgid "What to Change" msgstr "O que mudar" #. (itstool) path: row/entry #: article.translate.xml:542 article.translate.xml:549 #: article.translate.xml:556 article.translate.xml:563 #: article.translate.xml:601 msgid "share/xml/release.ent" msgstr "share/xml/release.ent" #. (itstool) path: row/entry #: article.translate.xml:543 msgid "" "Change beta.upcoming from IGNORE to " "INCLUDE" msgstr "" "Altere beta.upcoming de IGNORE para " "INCLUDE" #. (itstool) path: row/entry #: article.translate.xml:550 msgid "" "Change % beta.upcoming from IGNORE to " "INCLUDE" msgstr "" "Altere % beta.upcoming de IGNORE para " "INCLUDE" #. (itstool) path: row/entry #: article.translate.xml:557 msgid "" "Change beta.testing from IGNORE to " "INCLUDE" msgstr "" "Altere beta.testing de IGNORE para " "INCLUDE" #. (itstool) path: row/entry #: article.translate.xml:564 msgid "" "Change % beta.testing from IGNORE to " "INCLUDE" msgstr "" "Altere % beta.testing de IGNORE para " "INCLUDE" #. (itstool) path: sect2/title #: article.translate.xml:574 msgid "Website Changes During BETA or RC" msgstr "" "Alterações na página web durante a fase BETA ou " "RC" #. (itstool) path: sect2/para #: article.translate.xml:577 msgid "" "When transitioning from PRERELEASE to BETA, these files need to be updated to enable the \"Help Test\" block " "on the download page. All files are relative to head/ in the doc repository:" msgstr "" "Ao fazer a transição de PRERELEASE para BETA, esses arquivos precisam ser atualizados para ativar o bloco " "\"Teste de ajuda\" na página de download. Todos os arquivos são relativos ao " "head/ no repositório doc:" #. (itstool) path: row/entry #: article.translate.xml:594 msgid "en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml" msgstr "" "en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml" #. (itstool) path: row/entry #: article.translate.xml:595 msgid "" "Change % beta.local.where IGNORE to " "INCLUDE" msgstr "" "Altere % beta.local.where IGNORE para " "INCLUDE" #. (itstool) path: row/entry #: article.translate.xml:602 msgid "" "Update % betarel.vers to BETA1" msgstr "" "Atualize % betarel.vers para BETA1" #. (itstool) path: row/entry #: article.translate.xml:607 msgid "share/xml/news.xml" msgstr "share/xml/news.xml" #. (itstool) path: row/entry #: article.translate.xml:608 msgid "Add an entry announcing the BETA" msgstr "Adicione uma entrada anunciando a versão BETA" #. (itstool) path: row/entry #: article.translate.xml:613 msgid "" "en_US.ISO8859-1/htdocs/security/advisory-template.txt" msgstr "" "en_US.ISO8859-1/htdocs/security/advisory-template.txt" #. (itstool) path: row/entry #: article.translate.xml:614 article.translate.xml:621 msgid "" "Add the new BETA, RC, or final " "RELEASE to the template" msgstr "" "Adicione as novas BETA, RC ou " "RELEASE final ao modelo" #. (itstool) path: row/entry #: article.translate.xml:620 msgid "" "en_US.ISO8859-1/htdocs/security/errata-template.txt" msgstr "" "en_US.ISO8859-1/htdocs/security/errata-template.txt" #. (itstool) path: sect2/para #: article.translate.xml:629 msgid "" "Once the releng/12.0/ branch " "is created, the various release-related documents need to be generated and " "manually added to the doc/ repository." msgstr "" "Uma vez criada a branch releng/12.0/, os diversos documentos relacionados à release precisam ser gerados " "e adicionados manualmente ao repositório doc/." #. (itstool) path: sect2/para #: article.translate.xml:633 msgid "" "Within release/doc, invoke " "make1 to generate errata.html, " "hardware.html, readme.html, and " "relnotes.html pages, which are then added to doc/head/en_US.ISO8859-1/htdocs/releases/X." "YR/, where X.Y " "represents the major and minor version number of the release." msgstr "" "Dentro de release/doc, invoque " "make1 para gerar as páginas errata.html, " "hardware.html, readme.html e " "relnotes.html, que são então adicionadas ao diretório " "doc/head/en_US.ISO8859-1/htdocs/releases/" "XYR/, em que XY representa o número da versão principal e da versão secundária." #. (itstool) path: sect2/para #: article.translate.xml:643 msgid "" "The fbsd:nokeywords property must be set to on on the newly-added files before the pre-commit hooks will allow " "them to be added to the repository." msgstr "" "A propriedade fbsd:nokeywords deve ser definido como " "on nos arquivos recém-adicionados para que os hooks de " "pré-commit permitam que eles sejam adicionados ao repositório." #. (itstool) path: note/para #: article.translate.xml:649 msgid "" "The relevant release-related documents exist in the doc repository for FreeBSD 12.x and later." msgstr "" "Os documentos relevantes relacionados à release existem no repositório " "doc para FreeBSD 12.x e posterior." #. (itstool) path: sect2/title #: article.translate.xml:656 msgid "" "Ports Changes During BETA, RC, and the " "Final RELEASE" msgstr "" "Mudanças nos ports durante as fases BETA, RC, e a versão RELEASE final" #. (itstool) path: sect2/para #: article.translate.xml:660 msgid "" "For each build during the release cycle, the MANIFEST " "files containing the SHA256 of the various distribution " "sets, such as base.txz, kernel.txz, " "and so on, are added to the misc/freebsd-release-manifests port. This allows utilities other than " "bsdinstall8, such as ports-mgmt/poudriere, " "to safely use these distribution sets by providing a mechanism through which " "the checksums can be verified." msgstr "" "Para cada compilação durante o ciclo de release, os arquivos " "MANIFEST contendo o SHA256 dos vários " "conjuntos de distribuição, como base.txz, kernel." "txz, e assim por diante, são adicionados ao port misc/" "freebsd-release-manifests. Isso permite outros utilitários além do " "bsdinstall8, como ports-mgmt/poudriere, " "usem esses conjuntos de distribuição com segurança fornecendo um mecanismo " "através do qual os checksums possam ser verificados." #. (itstool) path: sect1/title #: article.translate.xml:680 msgid "Release from head/" msgstr "Versões oriundas da branch head/" #. (itstool) path: sect1/para #: article.translate.xml:683 msgid "" "This section describes the general procedures of the FreeBSD release cycle " "from the head/ branch." msgstr "" "Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD " "na branch head." #. (itstool) path: sect2/title #: article.translate.xml:687 msgid "FreeBSD ALPHA Builds" msgstr "Compilações ALPHA do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:689 msgid "" "Starting with the FreeBSD 10.0-RELEASE cycle, the notion of " "ALPHA builds was introduced. Unlike the " "BETA and RC builds, ALPHA builds are not included in the FreeBSD Release schedule." msgstr "" "Tendo aparecido primeiramente durante o ciclo de release do FreeBSD 10.0-" "RELEASE, a noção de compilações de fases ALPHA foi introduzida. Ao contrário das compilações BETA " "e RC, as compilações desse novo estágio ALPHA não fazem parte do cronograma de Release do FreeBSD." #. (itstool) path: sect2/para #: article.translate.xml:695 msgid "" "The idea behind ALPHA builds is to provide regular " "FreeBSD-provided builds before the creation of the stable/ branch." msgstr "" "A idéia por trás das compilações ALPHA é disponibilizar " "builds regulares fornecidas pelo FreeBSD antes da criação da branch " "stable/." #. (itstool) path: sect2/para #: article.translate.xml:699 msgid "" "FreeBSD ALPHA snapshots should be built approximately " "once a week." msgstr "" "Os snapshots ALPHA do FreeBSD devem ser preparados " "aproximadamente uma vez por semana." #. (itstool) path: sect2/para #: article.translate.xml:702 msgid "" "For the first ALPHA build, the BRANCH " "value in sys/conf/newvers.sh needs to be changed from " "CURRENT to ALPHA1. For subsequent " "ALPHA builds, increment each " "ALPHAN value by one." msgstr "" "Para a primeira compilação ALPHA, o valor " "BRANCH em sys/conf/newvers.sh " "precisa ser alterado de CURRENT para ALPHA1. Para compilações ALPHA subsequentes, incremente " "cada valor de ALPHAN em um." #. (itstool) path: sect2/para #: article.translate.xml:710 msgid "" "See for information on building the " "ALPHA images." msgstr "" "Veja para informações sobre como " "construir as imagens ALPHA." #. (itstool) path: sect2/title #: article.translate.xml:715 msgid "" "Creating the stable/12/ Branch" msgstr "" "Criando a branch stable/12/" #. (itstool) path: sect2/para #: article.translate.xml:717 msgid "" "When creating the stable/ branch, several changes are " "required in both the new stable/ branch and the " "head/ branch. The files listed are relative to the " "repository root. To create the new stable/12/ branch in Subversion:" msgstr "" "Ao criar a branch stable/, várias alterações são " "necessárias na nova branch stable/ e na branch " "head/. Os arquivos listados são relativos ao repositório " "raiz. Para criar a nova branch stable/12/" " no Subversion:" #. (itstool) path: sect2/screen #: article.translate.xml:723 #, no-wrap msgid "% svn cp ^/head stable/12/" msgstr "% svn cp ^/head stable/12/" #. (itstool) path: sect2/para #: article.translate.xml:725 msgid "" "Once the stable/12/ branch has " "been committed, make the following edits:" msgstr "" "Uma vez que a branch stable/12/ tenha sido criada, faça as seguintes edições:" #. (itstool) path: row/entry #: article.translate.xml:739 msgid "stable/12/UPDATING" msgstr "stable/12/UPDATING" #. (itstool) path: row/entry #: article.translate.xml:740 msgid "" "Update the FreeBSD version, and remove the notice about WITNESS" msgstr "" "Atualize a versão do FreeBSD e remova o aviso sobre WITNESS" #. (itstool) path: row/entry #: article.translate.xml:745 msgid "" "stable/12/contrib/jemalloc/include/" "jemalloc/jemalloc_FreeBSD.h" msgstr "" "stable/12/contrib/jemalloc/include/" "jemalloc/jemalloc_FreeBSD.h" #. (itstool) path: entry/screen #: article.translate.xml:746 #, no-wrap msgid "" "#ifndef MALLOC_PRODUCTION\n" "#define MALLOC_PRODUCTION\n" "#endif" msgstr "" "#ifndef MALLOC_PRODUCTION\n" "#define MALLOC_PRODUCTION\n" "#endif" #. (itstool) path: row/entry #: article.translate.xml:752 msgid "" "stable/12/lib/clang/llvm.build.mk" msgstr "" "stable/12/lib/clang/llvm.build.mk" #. (itstool) path: row/entry #: article.translate.xml:753 msgid "Uncomment -DNDEBUG" msgstr "Remova o comentário -DNDEBUG" #. (itstool) path: row/entry #: article.translate.xml:757 msgid "" "stable/12/sys/*/conf/GENERIC*" msgstr "" "stable/12/sys/*/conf/GENERIC*" #. (itstool) path: row/entry #: article.translate.xml:758 article.translate.xml:763 msgid "Remove debugging support" msgstr "Remova o suporte de depuração" #. (itstool) path: row/entry #: article.translate.xml:762 msgid "" "stable/12/sys/*/conf/MINIMAL" msgstr "" "stable/12/sys/*/conf/MINIMAL" #. (itstool) path: row/entry #: article.translate.xml:767 msgid "" "stable/12/release/release.conf.sample" msgstr "" "stable/12/release/release.conf.sample" #. (itstool) path: row/entry #: article.translate.xml:768 msgid "Update SRCBRANCH" msgstr "Atualize o SRCBRANCH" #. (itstool) path: row/entry #: article.translate.xml:772 msgid "" "stable/12/sys/*/conf/GENERIC-NODEBUG" msgstr "" "stable/12/sys/*/conf/GENERIC-NODEBUG" #. (itstool) path: row/entry #: article.translate.xml:773 msgid "Remove these kernel configurations" msgstr "Remova essas configurações do kernel" #. (itstool) path: row/entry #: article.translate.xml:777 msgid "" "stable/12/sys/arm/conf/std.arm*" msgstr "" "stable/12/sys/arm/conf/std.arm*" #. (itstool) path: row/entry #: article.translate.xml:778 msgid "Remove debugging options" msgstr "Remova as opções de depuração" #. (itstool) path: row/entry #: article.translate.xml:782 article.translate.xml:1062 msgid "" "stable/12/sys/conf/newvers.sh" msgstr "" "stable/12/sys/conf/newvers.sh" #. (itstool) path: row/entry #: article.translate.xml:783 msgid "" "Update the BRANCH value to reflect BETA1" msgstr "" "Atualize o valor de BRANCH para refletir BETA1" #. (itstool) path: row/entry #: article.translate.xml:788 msgid "" "stable/12/share/mk/src.opts.mk" msgstr "" "stable/12/share/mk/src.opts.mk" #. (itstool) path: row/entry #: article.translate.xml:789 msgid "" "Move REPRODUCIBLE_BUILD from " "__DEFAULT_NO_OPTIONS to __DEFAULT_YES_OPTIONS" msgstr "" "Mova REPRODUCIBLE_BUILD de __DEFAULT_NO_OPTIONS para __DEFAULT_YES_OPTIONS" #. (itstool) path: row/entry #: article.translate.xml:795 msgid "" "stable/12/libexec/rc/rc.conf" msgstr "" "stable/12/libexec/rc/rc.conf" #. (itstool) path: row/entry #: article.translate.xml:796 msgid "" "Set dumpdev from AUTO to NO (it is configurable via bsdinstall8 for those that want it " "enabled by default)" msgstr "" "Defina o dumpdev de AUTO para " "NO (ele é configurável via " "bsdinstall8 para aqueles que o querem habilitado por padrão)" #. (itstool) path: row/entry #: article.translate.xml:803 msgid "" "stable/12/release/Makefile" msgstr "" "stable/12/release/Makefile" #. (itstool) path: row/entry #: article.translate.xml:804 msgid "Remove the debug.witness.trace entries" msgstr "Remova as entradas debug.witness.trace" #. (itstool) path: sect2/para #: article.translate.xml:811 msgid "" "Then in the head/ branch, which will now become a new " "major version:" msgstr "" "Então, na branch head/, que agora se tornará uma nova " "versão principal:" #. (itstool) path: row/entry #: article.translate.xml:825 msgid "head/UPDATING" msgstr "head/UPDATING" #. (itstool) path: row/entry #: article.translate.xml:826 msgid "Update the FreeBSD version" msgstr "Atualize a versão do FreeBSD" #. (itstool) path: row/entry #: article.translate.xml:830 msgid "head/sys/conf/newvers.sh" msgstr "head/sys/conf/newvers.sh" #. (itstool) path: row/entry #: article.translate.xml:831 msgid "" "Update the BRANCH value to reflect CURRENT, and increment REVISION" msgstr "" "Atualize o valor de BRANCH para refletir " "CURRENT e incremente a REVISION" #. (itstool) path: row/entry #: article.translate.xml:837 msgid "head/Makefile.inc1" msgstr "head/Makefile.inc1" #. (itstool) path: row/entry #: article.translate.xml:838 msgid "" "Update TARGET_TRIPLE and MACHINE_TRIPLE" msgstr "" "Atualize o TARGET_TRIPLE e o MACHINE_TRIPLE" #. (itstool) path: row/entry #: article.translate.xml:843 msgid "head/sys/sys/param.h" msgstr "head/sys/sys/param.h" #. (itstool) path: row/entry #: article.translate.xml:844 msgid "Update __FreeBSD_version" msgstr "Atualize o __FreeBSD_version" #. (itstool) path: row/entry #: article.translate.xml:848 msgid "head/gnu/usr.bin/cc/cc_tools/freebsd-native.h" msgstr "head/gnu/usr.bin/cc/cc_tools/freebsd-native.h" #. (itstool) path: row/entry #: article.translate.xml:849 msgid "Update FBSD_MAJOR and FBSD_CC_VER" msgstr "" "Atualize o FBSD_MAJOR e o FBSD_CC_VER" #. (itstool) path: row/entry #: article.translate.xml:854 msgid "head/contrib/gcc/config.gcc" msgstr "head/contrib/gcc/config.gcc" #. (itstool) path: row/entry #: article.translate.xml:855 msgid "Append the freebsd<version>.h section" msgstr "Anexe a seção freebsd<versão>.h" #. (itstool) path: row/entry #: article.translate.xml:861 msgid "head/lib/clang/llvm.build.mk" msgstr "head/lib/clang/llvm.build.mk" #. (itstool) path: row/entry #: article.translate.xml:862 msgid "Update the value of OS_VERSION" msgstr "Atualize o valor do OS_VERSION" #. (itstool) path: row/entry #: article.translate.xml:881 msgid "head/lib/clang/freebsd_cc_version.h" msgstr "head/lib/clang/freebsd_cc_version.h" #. (itstool) path: row/entry #: article.translate.xml:882 msgid "Update FREEBSD_CC_VERSION" msgstr "Atualize o FREEBSD_CC_VERSION" #. (itstool) path: row/entry #: article.translate.xml:887 msgid "head/lib/clang/include/lld/Common/Version.inc" msgstr "head/lib/clang/include/lld/Common/Version.inc" #. (itstool) path: row/entry #: article.translate.xml:888 msgid "Update LLD_REVISION_STRING" msgstr "Atualize o LLD_REVISION_STRING" #. (itstool) path: row/entry #: article.translate.xml:893 msgid "head/Makefile.libcompat" msgstr "head/Makefile.libcompat" #. (itstool) path: row/entry #: article.translate.xml:894 article.translate.xml:951 msgid "Update LILB32CPUFLAGS" msgstr "Atualize o LILB32CPUFLAGS" #. (itstool) path: sect1/title #: article.translate.xml:909 msgid "Release from stable/" msgstr "Release a partir da branch stable/" #. (itstool) path: sect1/para #: article.translate.xml:911 msgid "" "This section describes the general procedures of the FreeBSD release cycle " "from an extablished stable/ branch." msgstr "" "Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD a " "partir de uma branch stable/." #. (itstool) path: sect2/title #: article.translate.xml:915 msgid "FreeBSD stable Branch Code Slush" msgstr "Code Slush da branch stable do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:917 msgid "" "In preparation for the code freeze on a stable branch, " "several files need to be updated to reflect the release cycle is officially " "in progress. These files are all relative to the top-most level of the " "stable branch:" msgstr "" "Na preparação para o code freeze em uma branch stable, " "vários arquivos precisam ser atualizados para refletir o ciclo de release " "que está oficialmente em andamento. Esses arquivos são todos relativos ao " "nível mais alto da branch stable:" #. (itstool) path: row/entry #: article.translate.xml:934 msgid "sys/conf/newvers.sh" msgstr "sys/conf/newvers.sh" #. (itstool) path: row/entry #: article.translate.xml:935 msgid "" "Update the BRANCH value to reflect PRERELEASE" msgstr "" "Atualize o valor da BRANCH para refletir " "PRERELEASE" #. (itstool) path: row/entry #: article.translate.xml:940 msgid "Makefile.inc1" msgstr "Makefile.inc1" #. (itstool) path: row/entry #: article.translate.xml:941 msgid "Update TARGET_TRIPLE" msgstr "Atualize o TARGET_TRIPLE" #. (itstool) path: row/entry #: article.translate.xml:945 msgid "lib/clang/llvm.build.mk" msgstr "lib/clang/llvm.build.mk" #. (itstool) path: row/entry #: article.translate.xml:946 msgid "Update OS_VERSION" msgstr "Atualize o OS_VERSION" #. (itstool) path: row/entry #: article.translate.xml:950 msgid "Makefile.libcompat" msgstr "Makefile.libcompat" #. (itstool) path: row/entry #: article.translate.xml:955 msgid "gnu/usr.bin/groff/tmac/mdoc.local.in" msgstr "gnu/usr.bin/groff/tmac/mdoc.local.in" #. (itstool) path: row/entry #: article.translate.xml:956 msgid "" "Add a new .ds entry for the FreeBSD version, and update " "doc-default-operating-system (FreeBSD 11.x and earlier " "only)" msgstr "" "Adiciona uma nova entrada .ds para a versão do FreeBSD, e " "atualiza doc-default-operating-system (FreeBSD 11.x e " "anteriores apenas)" #. (itstool) path: sect2/para #: article.translate.xml:965 msgid "" "In the doc repository, also update head/en_US." "ISO8859-1/htdocs/releases/12.0R/Makefile." "hardware, switching the value of _BRANCH to " "BETAX, " "RCX, or RELEASE, respectively." msgstr "" "No repositório doc, atualize também head/pt_BR." "ISO8859-1/htdocs/releases/12.0R/Makefile." "hardware, alternando o valor de _BRANCH para " "BETAX, " "RCX ou RELEASE, respectivamente." #. (itstool) path: sect2/title #: article.translate.xml:975 msgid "FreeBSD BETA Builds" msgstr "Builds BETA do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:977 msgid "" "Following the code slush, the next phase of the release cycle is the code " "freeze. This is the point at which all commits to the stable branch require " "explicit approval from the FreeBSD Release Engineering Team. This is " "enforced by pre-commit hooks in the Subversion repository by editing " "base/svnadmin/conf/approvers to include a regular " "expression matching the stable/12/ branch for the release:" msgstr "" "Após o code slush, a próxima fase do ciclo de release é o code freeze. Este " "é o ponto no qual todos os commits para a branch stable requerem aprovação " "explícita da Equipe de Engenharia de Release do FreeBSD. Isto é reforçado " "por hooks de pré-commit no repositório Subversion editando base/" "svnadmin/conf/approvers para incluir uma expressão regular que " "coincida com a branch stable/12/ para a release:" #. (itstool) path: sect2/programlisting #: article.translate.xml:986 #, no-wrap msgid "" "^/stable/12/\tre\n" "^/releng/12.0/\tre" msgstr "" "^/stable/12/\tre\n" "^/releng/12.0/\tre" #. (itstool) path: note/para #: article.translate.xml:990 msgid "" "There are two general exceptions to requiring commit approval during the " "release cycle. The first is any change that needs to be committed by the " "Release Engineer in order to proceed with the day-to-day workflow of the " "release cycle, the other is security fixes that may occur during the release " "cycle." msgstr "" "Há duas exceções gerais para exigir aprovação de commit durante o ciclo de " "release. A primeira é qualquer alteração que precise ser \"committed\" pelo " "Engenheiro de Release para continuar com o fluxo de trabalho diário do ciclo " "de lançamento, e a outra são as correções de segurança que podem ocorrer " "durante o ciclo de lançamento." #. (itstool) path: sect2/para #: article.translate.xml:998 msgid "" "Once the code freeze is in effect, the next build from the branch is labeled " "BETA1. This is done by updating the BRANCH value in sys/conf/newvers.sh from " "PRERELEASE to BETA1." msgstr "" "Quando o code freeze estiver em vigor, a próxima construção da branch será " "rotulada como BETA1. Isso é feito atualizando o valor de " "BRANCH em sys/conf/newvers.sh de " "PRERELEASE para BETA1." #. (itstool) path: sect2/para #: article.translate.xml:1005 msgid "" "Once this is done, the first set of BETA builds are " "started. Subsequent BETA builds do not require updates to " "any files other than sys/conf/newvers.sh, incrementing " "the BETA build number." msgstr "" "Feito isso, o primeiro conjunto de builds BETA é " "iniciado. Builds BETA subseqüentes não requerem " "atualizações em nenhum arquivo diferente do sys/conf/newvers.sh, incrementando o número de compilação da versão BETA." #. (itstool) path: sect2/title #: article.translate.xml:1013 msgid "" "Creating the releng/12.0/ " "Branch" msgstr "" "Criando a branch releng/12.0/" #. (itstool) path: sect2/para #: article.translate.xml:1015 msgid "" "When the first RC (Release Candidate) build is ready to " "begin, the releng/ branch is created. This is a multi-" "step process that must be done in a specific order, in order to avoid " "anomalies such as overlaps with __FreeBSD_version values, " "for example. The paths listed below are relative to the repository root. The " "order of commits and what to change are:" msgstr "" "Quando a primeira construção RC (Release Candidate) está " "pronta para começar, a branch releng/ é criada. Este é um " "processo de várias etapas que deve ser feito em uma ordem específica, a fim " "de evitar anomalias, como sobreposições com valores de __ " "FreeBSD_version, por exemplo. Os caminhos listados abaixo são " "relativos ao repositório raiz. A ordem dos commits e o que mudar são:" #. (itstool) path: sect2/screen #: article.translate.xml:1023 #, no-wrap msgid "% svn cp ^/stable/12/ releng/12.0/" msgstr "% svn cp ^/stable/12/ releng/12.0/" #. (itstool) path: row/entry #: article.translate.xml:1036 msgid "" "releng/12.0/sys/conf/newvers.sh" msgstr "" "releng/12.0/sys/conf/newvers.sh" #. (itstool) path: row/entry #: article.translate.xml:1037 msgid "" "Change BETAX to RC1" msgstr "" "Altere BETAX para " "RC1" #. (itstool) path: row/entry #: article.translate.xml:1043 msgid "" "releng/12.0/sys/sys/param.h" msgstr "" "releng/12.0/sys/sys/param.h" #. (itstool) path: row/entry #: article.translate.xml:1044 article.translate.xml:1070 msgid "Update __FreeBSD_version" msgstr "Atualize o __ FreeBSD_version" #. (itstool) path: row/entry #: article.translate.xml:1048 msgid "" "releng/12.0/etc/pkg/FreeBSD.conf" msgstr "" "releng/12.0/etc/pkg/FreeBSD.conf" #. (itstool) path: row/entry #: article.translate.xml:1049 article.translate.xml:1056 msgid "" "Replace latest with quarterly as the " "default package repository location" msgstr "" "Substitua latest por quarterly " "(trimestral) como a localização padrão do repositório de pacotes" #. (itstool) path: row/entry #: article.translate.xml:1055 msgid "" "releng/12.0/release/pkg_repos/release-" "dvd.conf" msgstr "" "releng/12.0/release/pkg_repos/release-" "dvd.conf" #. (itstool) path: row/entry #: article.translate.xml:1063 msgid "" "Update BETAX with " "PRERELEASE" msgstr "" "Atualize BETAX para " "PRERELEASE" #. (itstool) path: row/entry #: article.translate.xml:1069 msgid "" "stable/12/sys/sys/param.h" msgstr "" "stable/12/sys/sys/param.h" #. (itstool) path: row/entry #: article.translate.xml:1074 msgid "svnadmin/conf/approvers" msgstr "svnadmin/conf/approvers" #. (itstool) path: row/entry #: article.translate.xml:1075 msgid "" "Add a new approvers line for the releng branch as was done for the stable " "branch" msgstr "" "Adicione uma nova linha de aprovadores para a branch releng como foi feito " "para a branch stable" #. (itstool) path: sect2/screen #: article.translate.xml:1082 #, no-wrap msgid "" "% svn propdel -R svn:mergeinfo releng/12.0/\n" "% svn commit releng/12.0/\n" "% svn commit stable/12/" msgstr "" "% svn propdel -R svn:mergeinfo releng/12.0/\n" "% svn commit releng/12.0/\n" "% svn commit stable/12/" #. (itstool) path: sect2/para #: article.translate.xml:1086 msgid "" "Now that two new __FreeBSD_version values exist, also " "update head/en_US.ISO8859-1/books/porters-handbook/versions/" "chapter.xml in the Documentation Project repository." msgstr "" "Agora que existem dois novos valores de __ FreeBSD_version, também atualize head/pt_BR.ISO8859-1/books/porters-" "handbook/versions/chapter.xml no repositório do Projeto de " "Documentação." #. (itstool) path: sect2/para #: article.translate.xml:1091 msgid "" "After the first RC build has completed and tested, the " "stable/ branch can be thawed by removing " "(or commenting) the ^/stable/12/ entry in svnadmin/conf/approvers." msgstr "" "Depois que a primeira compilação de um RC estiver " "concluída e testada, a branch stable/ pode ser " "descongelada removendo (ou comentando) a entrada ^/" "stable/12/ em " "svnadmin/conf/approvers." #. (itstool) path: sect2/para #: article.translate.xml:1097 msgid "" "Following the availability of the first RC, FreeBSD " "Bugmeister Team should be emailed to add the new FreeBSD -RELEASE to the versions available in the drop-down menu " "shown in the bug tracker." msgstr "" "Seguindo a disponibilidade do primeiro RC, o Time " "Bugmeister do FreeBSD deve ser avisado por e-mail para adicionar o novo " "FreeBSD -RELEASE às versões " "disponíveis no menu drop-down exibido no rastreador de bugs." #. (itstool) path: sect1/title #: article.translate.xml:1112 msgid "Building FreeBSD Installation Media" msgstr "Construindo a Mídia de Instalação do FreeBSD" #. (itstool) path: sect1/para #: article.translate.xml:1114 msgid "" "This section describes the general procedures producing FreeBSD development " "snapshots and releases." msgstr "" "Esta seção descreve os procedimentos gerais de produção de snapshots e " "releases de desenvolvimento do FreeBSD." #. (itstool) path: sect2/title #: article.translate.xml:1118 msgid "Release Build Scripts" msgstr "Scripts para compilação de Releases" #. (itstool) path: sect2/para #: article.translate.xml:1120 msgid "" "This section describes the build scripts used by FreeBSD Release Engineering " "Team to produce development snapshots and releases." msgstr "" "Esta seção descreve os scripts de build usados pela Equipe de Engenharia de " "Release do FreeBSD para produzir snapshots da versão em desenvolvimento e " "das releases." #. (itstool) path: sect3/title #: article.translate.xml:1124 msgid "The release.sh Script" msgstr "O script release.sh" #. (itstool) path: sect3/para #: article.translate.xml:1126 msgid "" "Prior to FreeBSD 9.0-RELEASE, src/release/Makefile was " "updated to support bsdinstall8, and the src/" "release/generate-release.sh script was introduced as a wrapper to " "automate invoking the release7 targets." msgstr "" "Antes do FreeBSD 9.0-RELEASE, o src/release/Makefile " "era atualizado para suportar o bsdinstall8, e o script " "src/release/generate-release.sh foi introduzido como um " "wrapper para automatizar a chamada dos targets " "release7." #. (itstool) path: sect3/para #: article.translate.xml:1133 msgid "" "Prior to FreeBSD 9.2-RELEASE, src/release/release.sh " "was introduced, which heavily based on src/release/generate-" "release.sh included support to specify configuration files to " "override various options and environment variables. Support for " "configuration files provided support for cross building each architecture " "for a release by specifying a separate configuration file for each " "invocation." msgstr "" "Antes do FreeBSD 9.2-RELEASE, foi introduzido o src/release/" "release.sh, que baseado fortemente em src/release/" "generate-release.sh incluía suporte para especificar arquivos de " "configuração para substituir várias opções e variáveis de ambiente. O " "suporte para arquivos de configuração forneceu suporte para cross building " "(compilação para mais de uma arquitetura) de uma release para cada " "arquitetura, especificando um arquivo de configuração separado para cada " "chamada." #. (itstool) path: sect3/para #: article.translate.xml:1143 msgid "" "As a brief example of using src/release/release.sh to " "build a single release in /scratch:" msgstr "" "Como um breve exemplo do uso de src/release/release.sh " "para construir uma única versão em /scratch:" #. (itstool) path: sect3/screen #: article.translate.xml:1147 #, no-wrap msgid "# /bin/sh /usr/src/release/release.sh" msgstr "# /bin/sh /usr/src/release/release.sh" #. (itstool) path: sect3/para #: article.translate.xml:1149 msgid "" "As a brief example of using src/release/release.sh to " "build a single, cross-built release using a different target directory, " "create a custom release.conf containing:" msgstr "" "Como um breve exemplo do uso de src/release/release.sh " "para construir uma única versão cross-build (entre arquiteturas) usando um " "diretório de destino diferente, crie um release.conf " "personalizado contendo:" #. (itstool) path: sect3/programlisting #: article.translate.xml:1154 #, no-wrap msgid "" "# release.sh configuration for powerpc/powerpc64\n" "CHROOTDIR=\"/scratch-powerpc64\"\n" "TARGET=\"powerpc\"\n" "TARGET_ARCH=\"powerpc64\"\n" "KERNEL=\"GENERIC64\"" msgstr "" "# release.sh configuration for powerpc/powerpc64\n" "CHROOTDIR=\"/scratch-powerpc64\"\n" "TARGET=\"powerpc\"\n" "TARGET_ARCH=\"powerpc64\"\n" "KERNEL=\"GENERIC64\"" #. (itstool) path: sect3/para #: article.translate.xml:1160 msgid "Then invoke src/release/release.sh as:" msgstr "" "Em seguida, invoque src/release/release.sh da seguinte " "forma:" #. (itstool) path: sect3/screen #: article.translate.xml:1163 #, no-wrap msgid "# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf" msgstr "# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf" #. (itstool) path: sect3/para #: article.translate.xml:1165 msgid "" "See release7 and src/release/release.conf.sample for more details and example usage." msgstr "" "Veja release7 e src/release/release.conf.sample para mais detalhes e exemplos de uso." #. (itstool) path: sect3/title #: article.translate.xml:1171 msgid "The thermite.sh Wrapper Script" msgstr "O Script Wrapper thermite.sh" #. (itstool) path: sect3/para #: article.translate.xml:1174 msgid "" "In order to make cross building the full set of architectures supported on a " "given branch faster, easier, and reduce human error factors, a wrapper " "script around src/release/release.sh was written to " "iterate through the various combinations of architectures and invoke " "src/release/release.sh using a configuration file " "specific to that architecture." msgstr "" "Para tornar o cross building do conjunto completo de arquiteturas suportadas " "em uma determinada branch mais rápido, mais fácil e reduzindo os fatores de " "erro humano, um script wrapper de apoio ao src/release/release.sh foi escrito para iterar pelas várias combinações de arquiteturas e " "chamar o script src/release/release.sh usando um " "arquivo de configuração específico para essa arquitetura." #. (itstool) path: sect3/para #: article.translate.xml:1182 msgid "" "The wrapper script is called thermite.sh, which is " "available in the FreeBSD Subversion repository at svn://svn.freebsd." "org/base/user/gjb/thermite/, in addition to configuration files " "used to build head/ and stable/12/ development snapshots." msgstr "" "O script wrapper é chamado de thermite.sh, o qual está " "disponível no repositório Subversion do FreeBSD em svn://svn." "freebsd.org/base/user/gjb/thermite/ , além dos arquivos de " "configuração usados para construir os snapshots de desenvolvimento " "head/ e stable/12/." #. (itstool) path: sect3/para #: article.translate.xml:1190 msgid "" "Using thermite.sh is covered in and ." msgstr "" "O uso do thermite.sh é explicado em e ." #. (itstool) path: sect3/para #: article.translate.xml:1192 msgid "" "Each architecture and individual kernel have their own configuration file " "used by release.sh. Each branch has its own " "defaults-X.conf configuration which contains entries " "common throughout each architecture, where overrides or special variables " "are set and/or overridden in the per-build files." msgstr "" "Cada arquitetura e kernel individual tem seu próprio arquivo de configuração " "usado pelo release.sh. Cada branch tem sua própria " "configuração defaults-X.conf que contém entradas comuns " "em cada arquitetura, onde substituições ou variáveis especiais são definidas " "e/ou substituídas nos arquivos por compilação." #. (itstool) path: sect3/para #: article.translate.xml:1199 msgid "" "The per-build configuration file naming scheme is in the form of " "${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, where the " "uppercase variables are equivalent to what " "make1 uses in the build system, and lowercase variables are set " "within the configuration files, mapping to the major version of the " "respective branch." msgstr "" "O esquema de nomenclatura do arquivo de configuração por compilação está na " "forma de ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, em que as variáveis em maiúsculas são equivalentes a que " "make1 usa no sistema de compilação e as variáveis minúsculas são " "definidas nos arquivos de configuração, mapeando para a versão principal da " "respectiva branch." #. (itstool) path: sect3/para #: article.translate.xml:1207 msgid "" "Each branch also has its own builds-X.conf " "configuration, which is used by thermite.sh. The " "thermite.sh script iterates through each ${revision}, " "${TARGET_ARCH}, ${KERNCONF}, and ${type} value, creating a master list of " "what to build. However, a given combination from the list will only be built " "if the respective configuration file exists, which is where the naming " "scheme above is relevant." msgstr "" "Cada branch também possui sua própria configuração builds-X.conf, que é usada pelo thermite.sh. O script " "thermite.sh itera através de cada valor ${revision}, " "${TARGET_ARCH}, ${KERNCONF} e ${type}, criando uma lista principal do que " "construir. No entanto, uma determinada combinação da lista só será criada se " "o respectivo arquivo de configuração existir, que é onde o esquema de " "nomenclatura acima é relevante." #. (itstool) path: sect3/para #: article.translate.xml:1218 msgid "There are two paths of file sourcing:" msgstr "Existem dois caminhos de fornecimento de arquivos:" #. (itstool) path: listitem/para #: article.translate.xml:1222 msgid "" "builds-12.conf -> " "main.conf" msgstr "" "builds-12.conf -> " "main.conf" #. (itstool) path: listitem/para #: article.translate.xml:1224 msgid "This controls thermite.sh behavior" msgstr "Isto controla o comportamento do thermite.sh" #. (itstool) path: listitem/para #: article.translate.xml:1229 msgid "" "12-amd64-" "GENERIC-snap.conf -> defaults-12.conf -> main.conf" msgstr "" "12-amd64-" "GENERIC-snap.conf -> defaults-12.conf -> main.conf" #. (itstool) path: listitem/para #: article.translate.xml:1233 msgid "" "This controls release/release.sh behavior within the " "build chroot8" msgstr "" "Isto controla o comportamento do release/release.sh " "dentro do chroot8 de compilação" #. (itstool) path: note/para #: article.translate.xml:1239 msgid "" "The builds-12.conf, " "defaults-12.conf, and " "main.conf configuration files exist to reduce " "repetition between the various per-build files." msgstr "" "Os arquivos de configuração builds-12." "conf, defaults-12.conf, e main.conf existem para reduzir a repetição " "entre os vários arquivos por compilação." #. (itstool) path: sect2/title #: article.translate.xml:1250 msgid "Building FreeBSD Development Snapshots" msgstr "Construindo Snapshots de Desenvolvimento do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:1252 msgid "" "The official release build machines have a specific filesystem layout, which " "using ZFS, thermite.sh takes heavy " "advantage of with clones and snapshots, ensuring a pristine build " "environment." msgstr "" "As máquinas oficiais de compilação de versões têm um layout do sistema de " "arquivos específico, que utiliza ZFS, o " "thermite.sh tira grande proveito de clones e snapshots, " "garantindo um ambiente de compilação uniforme e consistente." #. (itstool) path: sect2/para #: article.translate.xml:1258 msgid "" "The build scripts reside in /releng/scripts-" "snapshot/scripts or /releng/scripts-" "release/scripts respectively, to avoid collisions between an " "RC build from a releng branch versus a STABLE snapshot from the respective stable branch." msgstr "" "Os scripts de compilação localizam-se respectivamente em /releng/scripts-snapshot/scripts ou /releng/scripts-release/scripts, para evitar " "colisões entre uma compilação RC de uma branch releng " "contra um snapshot STABLE da respectiva branch stable." #. (itstool) path: sect2/para #: article.translate.xml:1265 msgid "" "A separate dataset exists for the final build images, /snap/ftp. This directory contains both snapshots " "and releases directories. They are only used if the " "EVERYTHINGISFINE variable is defined in main." "conf." msgstr "" "Existe um dataset (conjunto de dados) separado para as imagens finais de " "compilação, /snap/ftp. Este " "diretório contém diretórios de snapshots e releases. Eles são usados apenas " "se a variável EVERYTHINGISFINE estiver definida em " "main.conf." #. (itstool) path: note/para #: article.translate.xml:1272 msgid "" "The EVERYTHINGISFINE variable name was chosen to avoid " "colliding with a variable that might be possibly set in the user " "environment, accidentally enabling the behavior that depends on it being " "defined." msgstr "" "O nome da variável EVERYTHINGISFINE foi escolhido para " "evitar a colisão com uma variável possivelmente definida no ambiente do " "usuário, ativando acidentalmente o comportamento que depende de sua " "definição." #. (itstool) path: sect2/para #: article.translate.xml:1278 msgid "" "As thermite.sh iterates through the master list of " "combinations and locates the per-build configuration file, a ZFS dataset is created under /releng, such as /releng/12-amd64-GENERIC-" "snap. The src/, ports/, and " "doc/ trees are checked out to separate ZFS datasets, such as /releng/12-src-" "snap, which are then cloned and mounted into the respective build " "datasets. This is done to avoid checking out a given tree more than once." msgstr "" "Como o thermite.sh percorre a lista principal de " "combinações e localiza o arquivo de configuração por compilação, um dataset " "ZFS é criado sob o /releng, tal como /releng/12-amd64-GENERIC-" "snap. O checkout das árvores src/, " "ports/ e doc/ é realizado em " "diferentes datasets ZFS, tal como /releng/12-src-snap, os quais são então clonados e " "montados nos respectivos datasets de compilação. Isso é feito para evitar a " "remoção de uma determinada árvore mais de uma vez." #. (itstool) path: sect2/para #: article.translate.xml:1290 msgid "" "Assuming these filesystem paths, thermite.sh would be " "invoked as:" msgstr "" "Assumindo esses caminhos do sistema de arquivos, o thermite.sh deveria ser chamado como:" #. (itstool) path: sect2/screen #: article.translate.xml:1293 #, no-wrap msgid "" "# cd /releng/scripts-snapshot/scripts\n" "# ./setrev.sh -b stable/12/\n" -"# ./zfs-setup.sh -c ./builds-12.conf\n" +"# ./zfs-cleanup.sh -c ./builds-12.conf\n" "# ./thermite.sh -c ./builds-12.conf" msgstr "" "# cd /releng/scripts-snapshot/scripts\n" "# ./setrev.sh -b stable/12/\n" -"# ./zfs-setup.sh -c ./builds-12.conf\n" +"# ./zfs-cleanup.sh -c ./builds-12.conf\n" "# ./thermite.sh -c ./builds-12.conf" #. (itstool) path: sect2/para #: article.translate.xml:1298 msgid "" "Once the builds have completed, additional helper scripts are available to " "generate development snapshot emails which are sent to the freebsd-" "snapshots@freebsd.org mailing list:" msgstr "" "Quando as compilações forem concluídas, scripts adicionais auxiliares " "estarão disponíveis para gerar e-mails de snapshots de desenvolvimento que " "são enviados para a lista de e-mail freebsd-snapshots@freebsd.org:" #. (itstool) path: sect2/screen #: article.translate.xml:1303 #, no-wrap msgid "" "# cd /releng/scripts-snapshot/scripts\n" "# ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mail" msgstr "" "# cd /releng/scripts-snapshot/scripts\n" "# ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mail" #. (itstool) path: note/para #: article.translate.xml:1307 msgid "" "The generated output should be double-checked for correctness, and the email " "itself should be PGP signed, in-line." msgstr "" "A saída gerada deve ser checada duas vezes para garantir a exatidão, e o " "próprio e-mail deve ter assinatura PGP, in-line (no arquivo)." #. (itstool) path: note/para #: article.translate.xml:1313 msgid "" "These helper scripts only apply to development snapshot builds. " "Announcements during the release cycle (excluding the final release " "announcement) are created from an email template. A sample of the email " "template currently used can be found here." msgstr "" "Esses scripts auxiliares aplicam-se apenas às compilações de snapshot " "(versão instantânea) de desenvolvimento. Os anúncios durante o ciclo de " "lançamento (excluindo o anúncio de versão final) são criados a partir de um " "modelo de email. Uma amostra do modelo de email usado atualmente pode ser " "encontrada aqui." #. (itstool) path: sect2/title #: article.translate.xml:1322 msgid "Building FreeBSD Releases" msgstr "Construindo Releases do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:1324 msgid "" "Similar to building FreeBSD development snapshots, thermite.sh would be invoked the same way. The difference between development " "snapshots and release builds, BETA and RC included, is that the chroot8 configuration files " "must be named with release instead of snap as the \"type\", as mentioned above." msgstr "" "Similar a compilação de snapshots de desenvolvimento do FreeBSD, o " "thermite.sh seria invocado da mesma maneira. A " "diferença entre snapshots de desenvolvimento e builds de releases, " "BETA e RC inclusos, é que os arquivos " "de configuração do chroot8 devem ser nomeados com " "release ao invés de snap no \"type\", " "como mencionado acima." #. (itstool) path: sect2/para #: article.translate.xml:1332 msgid "" "In addition, the BUILDTYPE and types " "must be changed from snap to release " "in defaults-12.conf and " "builds-12.conf, respectively." msgstr "" "Além disso, BUILDTYPE e types devem " "ser alterados de snap para release em " "defaults-12.conf e " "builds-12.conf, " "respectivamente." #. (itstool) path: sect2/para #: article.translate.xml:1340 msgid "" "When building BETA, RC, and the final " "RELEASE, also statically set BUILDSVNREV to the revision on the branch reflecting the name change, " "BUILDDATE to the date the builds are started in " "YYYYMMDD format. If the doc/ and " "ports/ trees have been tagged, also set " "PORTBRANCH and DOCBRANCH to the " "relevant tag path in the Subversion repository, replacing HEAD with the last changed revision. Also set releasesrc in builds-12.conf " "to the relevant branch, such as stable/12/ or releng/12.0/." msgstr "" "Ao construir o BETA, o RC, e o " "RELEASE final, também ajuste estaticamente o " "BUILDSVNREV para a revisão na branch refletindo a mudança " "de nome, BUILDDATE para a data em que as compilações são " "iniciadas no formato YYYYMMDD. Se as árvores doc/" " e ports/ tiverem sido marcadas, defina também " "o PORTBRANCH e o DOCBRANCH para o " "caminho da tag relevante no repositório Subversion, substituindo " "HEAD pela última revisão alterada. Também defina " "releasesrc em builds-12.conf para a branch relevante, como stable/" "12/ ou releng/" "12.0/." #. (itstool) path: sect2/para #: article.translate.xml:1356 msgid "" "During the release cycle, a copy of CHECKSUM.SHA512 and " "CHECKSUM.SHA256 for each architecture are stored in the " "FreeBSD Release Engineering Team internal repository in addition to being " "included in the various announcement emails. Each MANIFEST containing the hashes of base.txz, " "kernel.txz, etc. are added to misc/freebsd-" "release-manifests in the Ports Collection, as well." msgstr "" "Durante o ciclo de release, uma cópia do CHECKSUM.SHA512 e do CHECKSUM.SHA256 para cada arquitetura é " "armazenada no repositório interno da Equipe de Engenharia de Release do " "FreeBSD, além de ser incluída nos diversos e-mails de anúncio. Cada " "MANIFEST contendo os hashes do base.txz, do kernel.txz, etc. também são adicionados " "ao misc/freebsd-release-manifests na coleção de ports." #. (itstool) path: sect2/para #: article.translate.xml:1367 msgid "" "After building the final RELEASE, the releng/" "12.0/ branch is tagged as " "release/12.0.0/ using the " "revision from which the RELEASE was built. Similar to " "creating the stable/12/ and " "releng/12.0/ branches, this is " "done with svn cp. From the repository root:" msgstr "" "Depois de construir a RELEASE final, a branch " "releng/12.0/ é marcada como " "release/12.0.0/ usando a " "revisão a partir da qual a RELEASE foi construída. " "Semelhante a criar as branches stable/12/" " e releng/12.0/, " "isso é feito com svn cp. Da raiz do repositório:" #. (itstool) path: sect2/screen #: article.translate.xml:1374 #, no-wrap msgid "" "% svn cp ^/releng/12.0/@r306420 release/12.0.0/\n" "% svn commit release/12.0.0/" msgstr "" "% svn cp ^/releng/12.0/@r306420 release/12.0.0/\n" "% svn commit release/12.0.0/" #. (itstool) path: sect1/title #: article.translate.xml:1386 msgid "Publishing FreeBSD Installation Media to Project Mirrors" msgstr "Publicando a Mídia de Instalação do FreeBSD nos Espelhos do Projeto" #. (itstool) path: sect1/para #: article.translate.xml:1388 msgid "" "This section describes the procedure to publish FreeBSD development " "snapshots and releases to the Project mirrors." msgstr "" "Esta seção descreve o procedimento para publicar snapshots e releases de " "desenvolvimento do FreeBSD nos espelhos do Projeto." #. (itstool) path: sect2/title #: article.translate.xml:1392 msgid "Staging FreeBSD Installation Media Images" msgstr "Preparando Imagens de Mídias de Instalação do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:1394 msgid "Staging FreeBSD snapshots and releases is a two part process:" msgstr "" "A preparação dos snapshots e das versões do FreeBSD é um processo de duas " "partes:" #. (itstool) path: listitem/para #: article.translate.xml:1399 msgid "" "Creating the directory structure to match the hierarchy on ftp-" "master" msgstr "" "Criando a estrutura de diretórios para corresponder a hierarquia em " "ftp-master" #. (itstool) path: listitem/para #: article.translate.xml:1402 msgid "" "If EVERYTHINGISFINE is defined in the build configuration " "files, main.conf in the case of the build scripts " "referenced above, this happens automatically in the " "chroot8 after the build is complete, creating the directory structure " "in ${DESTDIR}/R/ftp-stage with a " "path structure matching what is expected on ftp-master. This is equivalent to running the following in the " "chroot8 directly:" msgstr "" "Se EVERYTHINGISFINE for definido nos arquivos de " "configuração de compilação, main.conf no caso dos " "scripts de compilação mencionados acima, isto acontece automaticamente no " "chroot8 após a compilação ser concluída, criando a estrutura de " "diretório em ${DESTDIR}/R/ftp-stage " "com um estrutura de caminho que corresponde ao que é esperado em " "ftp-master. Isto é equivalente a executar o " "seguinte diretamente no chroot " "8:" #. (itstool) path: listitem/screen #: article.translate.xml:1411 #, no-wrap msgid "# make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage" msgstr "# make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage" #. (itstool) path: listitem/para #: article.translate.xml:1413 msgid "" "After each architecture is built, thermite.sh will " "rsync the " "${DESTDIR}/R/ftp-stage from the build " "chroot8 to /snap/ftp/snapshots or /snap/ftp/releases on " "the build host, respectively." msgstr "" "Depois que cada arquitetura é compilada, o thermite.sh " "irá fazer um rsync do ${DESTDIR}/R/ftp-stage da compilação " "chroot8 para o diretório /snap/ftp/" "snapshots ou /snap/ftp/releases no host de compilação, respectivamente." #. (itstool) path: listitem/para #: article.translate.xml:1422 msgid "" "Copying the files to a staging directory on ftp-master before moving the files into pub/ to begin propagation to the Project mirrors" msgstr "" "Copiando os arquivos para um diretório temporário em ftp-master " " antes de mover os arquivos para pub/ para iniciar a propagação para os servidores espelhos do " "Projeto" #. (itstool) path: listitem/para #: article.translate.xml:1427 msgid "" "Once all builds have finished, /snap/ftp/" "snapshots, or /snap/ftp/releases for a release, is polled by ftp-master " "using rsync to /" "archive/tmp/snapshots or /archive/" "tmp/releases, respectively." msgstr "" "Uma vez que todas as compilações terminarem, /" "snap/ftp/snapshots, ou /snap/ftp/" "releases para uma versão, é pesquisado pelo ftp-" "master usando rsync para /archive/tmp/snapshots ou /archive/tmp/releases, respectivamente." #. (itstool) path: note/para #: article.translate.xml:1436 msgid "" "On ftp-master in the FreeBSD Project " "infrastructure, this step requires root level access, as " "this step must be executed as the archive user." msgstr "" "No ftp-master na infraestrutura do Projeto FreeBSD, " "esta etapa requer acesso ao nível de root, já que esta " "etapa deve ser executada como o usuário archive." #. (itstool) path: sect2/title #: article.translate.xml:1446 msgid "Publishing FreeBSD Installation Media" msgstr "Publicando a Mídia de Instalação do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:1448 msgid "" "Once the images are staged in /archive/tmp/, they are ready to be made public by putting them in /archive/pub/FreeBSD. In order to reduce " "propagation time, pax1 is used to create hard " "links from /archive/tmp to " "/archive/pub/FreeBSD." msgstr "" "Uma vez que as imagens são colocadas em /" "archive/tmp/, elas estão prontas para serem publicadas colocando-" "as em /archive/pub/FreeBSD. Para " "reduzir o tempo de propagação, o pax1 é usado para criar " "links físicos a partir de /archive/tmp para /archive/pub/FreeBSD." #. (itstool) path: note/para #: article.translate.xml:1455 msgid "" "In order for this to be effective, both /" "archive/tmp and /archive/pub must reside on the same logical filesystem." msgstr "" "Para que isto seja efetivo, tanto o /archive/" "tmp quanto o /archive/pub devem residir no mesmo sistema de arquivos lógico." #. (itstool) path: sect2/para #: article.translate.xml:1459 msgid "" "There is a caveat, however, where rsync must be " "used after pax1 in order to correct the symbolic links in " "pub/FreeBSD/snapshots/ISO-IMAGES which pax1 will replace with a " "hard link, increasing the propagation time." msgstr "" "Há uma ressalva, no entanto, em que o rsync deve " "ser usado após o pax1 para corrigir os links " "simbólicos no pub/FreeBSD/" "snapshots/ISO-IMAGES que o " "pax1 irá substituir por um hard link, aumentando o tempo de " "propagação." #. (itstool) path: note/para #: article.translate.xml:1466 msgid "" "As with the staging steps, this requires root level " "access, as this step must be executed as the archive user." msgstr "" "Assim como nas etapas de preparação, isto requer acesso em nível de " "root, já que essa etapa deve ser executada como o " "usuário archive." #. (itstool) path: sect2/para #: article.translate.xml:1471 msgid "As the archive user:" msgstr "Como o usuário archive:" #. (itstool) path: sect2/screen #: article.translate.xml:1473 #, no-wrap msgid "" "% cd /archive/tmp/snapshots\n" "% pax -r -w -l . /archive/pub/FreeBSD/snapshots\n" "% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/" msgstr "" "% cd /archive/tmp/snapshots\n" "% pax -r -w -l . /archive/pub/FreeBSD/snapshots\n" "% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/" #. (itstool) path: sect2/para #: article.translate.xml:1477 msgid "" "Replace snapshots with releases as appropriate." msgstr "" "Substitua os snapshots por releases conforme apropriado." #. (itstool) path: sect1/title #: article.translate.xml:1484 msgid "Wrapping up the Release Cycle" msgstr "Encerrando o Ciclo de Release" #. (itstool) path: sect1/para #: article.translate.xml:1486 msgid "This section describes general post-release tasks." msgstr "Esta seção descreve as tarefas gerais de pós-release." #. (itstool) path: sect2/title #: article.translate.xml:1489 msgid "Post-Release Errata Notices" msgstr "Avisos de Erratas de Pós-Release" #. (itstool) path: sect2/para #: article.translate.xml:1491 msgid "" "As the release cycle approaches conclusion, it is common to have several " "EN (Errata Notice) candidates to address issues that were " "discovered late in the cycle. Following the release, the FreeBSD Release " "Engineering Team and the FreeBSD Security Team revisit changes that were not " "approved prior to the final release, and depending on the scope of the " "change in question, may issue an EN." msgstr "" "A medida que o ciclo de release se aproxima da conclusão, é comum ter vários " "candidatos a EN (Aviso de Erratas) para abordar os " "problemas que foram descobertos ao final do ciclo. Após o lançamento, a " "Equipe de Engenharia de Release do FreeBSD e a Equipe de Segurança do " "FreeBSD reveem mudanças que não foram aprovadas antes da versão final, e " "dependendo do escopo da mudança em questão, podem emitir um EN." #. (itstool) path: note/para #: article.translate.xml:1500 msgid "" "The actual process of issuing ENs is handled by the " "FreeBSD Security Team." msgstr "" "O processo atual de emissão de ENs é tratado pela Equipe " "de Segurança do FreeBSD." #. (itstool) path: sect2/para #: article.translate.xml:1504 msgid "" "To request an Errata Notice after a release cycle has completed, a developer " "should fill out the Errata Notice template, in particular the " "Background, Problem Description, " "Impact, and if applicable, Workaround " "sections." msgstr "" "Para solicitar uma Errata após a conclusão de um ciclo de lançamento, o " "desenvolvedor deve preencher o Template de Errata>, em particular as " "seções Background, Problem Description, Impact e, se aplicável, as seções " "Workaround." #. (itstool) path: sect2/para #: article.translate.xml:1511 msgid "" "The completed Errata Notice template should be emailed together with either " "a patch against the releng/ branch or a list of revisions " "from the stable/ branch." msgstr "" "O modelo de Errata preenchido deve ser enviado por e-mail juntamente com um " "patch na branch releng/ ou uma lista de revisões da " "branch stable/." #. (itstool) path: sect2/para #: article.translate.xml:1516 msgid "" "For Errata Notice requests immediately following the release, the request " "should be emailed to both the FreeBSD Release Engineering Team and the " "FreeBSD Security Team. Once the releng/ branch has been " "handed over to the FreeBSD Security Team as described in , Errata Notice requests should be sent to the " "FreeBSD Security Team." msgstr "" "Para pedidos de Errata imediatamente após o lançamento, o pedido deve ser " "enviado por e-mail à Equipe de Engenharia de Releases do FreeBSD e à Equipe " "de Segurança do FreeBSD. Depois que a branch releng/ foi " "entregue à equipe de Segurança do FreeBSD, conforme descrito em , as solicitações de Errata devem ser " "enviadas à equipe de Segurança do FreeBSD." #. (itstool) path: sect2/title #: article.translate.xml:1524 msgid "Handoff to the FreeBSD Security Team" msgstr "Entrega para a Equipe de Segurança do FreeBSD" #. (itstool) path: sect2/para #: article.translate.xml:1526 msgid "" "Roughly two weeks following the release, the Release Engineer updates " "svnadmin/conf/approvers changing the approver column " "from re to (so|security-officer) for " "the releng/12.0/ branch." msgstr "" "Aproximadamente duas semanas após o lançamento, o Engenheiro de Release " "atualiza o svnadmin/conf/approvers alterando a coluna " "do aprovador de re para (so|security-officer) para a branch releng/12.0/."