                        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 "(TM)" or the "(R)"
   symbol.

   2020-11-22 20:57:38 +0000 por Danilo G. Baio.
   Resumo

   Este artigo descreve o processo por tras do modelo de engenharia de
   release adotado pelo Projeto FreeBSD.

   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Introduc,ao ao Processo de Engenharia de Release do FreeBSD

   2. Informac,ao Geral e Preparativos

   3. Terminologia da Engenharia de Release

   4. Alterac,oes na Pagina Web Durante o Ciclo de Release

   5. Releases a partir da branch head/

   6. Release a partir da branch stable/

   7. Construindo a Midia de Instalac,ao do FreeBSD

   8. Publicando a Midia de Instalac,ao do FreeBSD nos Espelhos do Projeto

   9. Encerrando o Ciclo de Release

   10. Fim de Vida (End-of-Life) de Releases

1. Introduc,ao ao Processo de Engenharia de Release do FreeBSD

   O desenvolvimento do FreeBSD segue um fluxo muito especifico. Em geral,
   todas as mudanc,as no sistema base do FreeBSD sao feitas em uma branch
   chamada head/, a qual reflete o topo da arvore de codigo fonte.

   Apos um periodo razoavel de testes, as alterac,oes podem ser fundidas na
   branch stable/. O periodo de tempo minimo padrao antes da fusao das
   alterac,oes na branch stable/ e de tres (3) dias.

   Embora seja uma regra geral esperar pelo menos tres (3) dias antes de
   fundir o codigo produzido na branch head/, existem algumas circunstancias
   especiais em que uma fusao imediata pode ser necessaria, tal como uma
   correc,ao de seguranc,a critica ou uma correc,ao de bug que inibe
   diretamente o processo de compilac,ao de uma release.

   Apos varios meses, quando o numero de mudanc,as na branch stable/ cresceu
   significativamente, e hora de lanc,ar a proxima versao do FreeBSD. Essas
   versoes foram historicamente chamadas de "point" releases.

   Entre as versoes das branches stable/, aproximadamente a cada dois (2)
   anos, uma nova versao e criada vinda diretamente da branch head/. Essas
   versoes foram historicamente chamadas de versoes "dot-zero".

   Este artigo ira destacar o fluxo de trabalho e as responsabilidades da
   Equipe de Engenharia de Release do FreeBSD para ambas as versoes
   "dot-zero" e "point release".

   As sec,oes a seguir deste artigo descrevem:

   Sec,ao 2, "Informac,ao Geral e Preparativos"

           Informac,oes gerais e preparativos antes de iniciar o ciclo de
           release.

   Sec,ao 4, "Alterac,oes na Pagina Web Durante o Ciclo de Release"

           Alterac,oes na Pagina Web Durante o Ciclo de Release

   Sec,ao 3, "Terminologia da Engenharia de Release"

           Terminologia e informac,oes gerais, como "code slush" e "code
           freeze", usadas por todo este documento.

   Sec,ao 5, "Releases a partir da branch head/"

           O processo de Engenharia de Release para uma versao "dot-zero".

   Sec,ao 6, "Release a partir da branch stable/"

           O processo de Engenharia de Release para uma versao "point
           release".

   Sec,ao 7, "Construindo a Midia de Instalac,ao do FreeBSD"

           Informac,oes relacionadas aos procedimentos especificos para
           construir o meio de instalac,ao.

   Sec,ao 8, "Publicando a Midia de Instalac,ao do FreeBSD nos Espelhos do
   Projeto"

           Procedimentos para publicar um meio de instalac,ao.

   Sec,ao 9, "Encerrando o Ciclo de Release"

           Encerrando o ciclo de release.

2. Informac,ao Geral e Preparativos

   Aproximadamente dois meses antes do inicio do ciclo de vida de uma nova
   versao, a Equipe de Engenharia de Release do FreeBSD decide sobre um
   cronograma para o seu lanc,amento. A programac,ao inclui os varios
   milestones do ciclo de release, como datas de congelamento, datas para as
   branches e datas para compilac,ao do codigo. Por exemplo:

                  Milestone                     Data prevista     
   pre 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   
   Pre congelamento da arvore doc/ [1]:     24 de junho de 2016   
   Branch trimestral dos ports [2]:         1-o de julho de 2016  
   branch stable/12/:                       8 de julho de 2016    
   Aplicac,ao da tag na arvore doc/ [3]:    8 de julho de 2016    
   Comec,a a compilac,ao da fase BETA1:     8 de julho de 2016    
   descongelamento da branch head/:         9 de julho de 2016    
   Comec,a a compilac,ao da fase BETA2:     15 de julho de 2016   
   Comec,a a compilac,ao da fase BETA3 [*]: 22 de julho de 2016   
   branch releng/12.0/:                     29 de julho de 2016   
   A compilac,ao da fase RC1 e iniciada:    29 de julho de 2016   
   descongelamento da branch stable/12/:    30 de julho de 2016   
   Comec,a a compilac,ao da fase RC2:       5 de agosto de 2016   
   Ultima compilac,ao dos ports [4]:        6 de agosto de 2016   
   Aplicac,ao da tag na arvore dos ports:   12 de agosto de 2016  
   compilac,ao da fase RC3 [*]:             12 de agosto de 2016  
   inicio de compilac,ao da RELEASE:        19 de agosto de 2016  
   Anuncio da RELEASE:                      2 de setembro de 2016 

  Nota:

   Itens marcados com "[*]" identificam passos executados apenas "conforme
   necessario".

    1. O pre congelamento da arvore doc e coordenado pela Equipe de
       Engenharia de Documentac,ao do FreeBSD.

    2. A branch trimestral da arvore da colec,ao de ports e determinada
       quando a compilac,ao final da fase RC e planejada. Uma nova branch
       trimestral e criada no primeiro dia do trimestre, portanto, essa
       metrica deve ser usada ao considerar os marcos do ciclo de release.
       Uma branch trimestral e criada pela Equipe de Gerenciamento de Ports
       do FreeBSD.

    3. A arvore doc e recebe a tag da Equipe de Engenharia de Documentac,ao
       do FreeBSD.

    4. A compilac,ao final dos pacotes e feita pela Equipe de Gerenciamento
       de Ports do FreeBSD apos a compilac,ao final (ou o que e esperada ser
       a final) de uma fase RC.

  Nota:

   Se a versao RELEASE estiver sendo criada a partir de uma branch stable
   existente, a data de congelamento do KBI podera ser excluida, ja que o KBI
   ja esta congelado em branchs stable.

   Ao escrever o cronograma do ciclo de versoes, varias coisas precisam ser
   levadas em considerac,ao, em particular os milestones nos quais a data
   alvo depende de milestones pre-definidos sobre os quais existe uma
   dependencia. Por exemplo, a aplicac,ao da tag de release da Colec,ao de
   Ports e originada da branch trimestral ativa no momento da ultima fase do
   RC. Isso em parte define qual branch trimestral e usada, quando a
   aplicac,ao da tag pode acontecer e qual revisao da arvore de ports e usada
   para a construc,ao 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.

   E normal que muitos desenvolvedores informem a Equipe de Engenharia de
   Release do FreeBSD sobre varios trabalhos em andamento. Em alguns casos,
   uma extensao para o trabalho em andamento sera solicitada e, em outros
   casos, uma solicitac,ao para uma "aprovac,ao geral" para um subconjunto
   especifico da arvore sera feita.

   Quando tais solicitac,oes sao feitas, e importante certificar-se de que os
   cronogramas (mesmo que estimados) sejam discutidos. Para as aprovac,oes
   gerais, o periodo de tempo para a aprovac,ao geral deve ser claro. Por
   exemplo, um desenvolvedor do FreeBSD pode solicitar aprovac,oes gerais
   desde o inicio do code slush ate o inicio da construc,ao da primeira RC.

  Nota:

   Para manter o controle das aprovac,oes gerais, a Equipe de Engenharia de
   Release do FreeBSD usa um repositorio interno para manter um registro de
   tais solicitac,oes, que define a area na qual uma aprovac,ao geral foi
   concedida, o(s) autor(es), quando a aprovac,ao geral expira e a razao pela
   qual a aprovac,ao foi concedida. Um exemplo disso e a concessao de uma
   aprovac,ao geral na release/doc/ a todos os membros da Equipe de
   Engenharia de Release do FreeBSD ate o RC final para atualizar as notas de
   lanc,amento e outras documentac,ao relacionada ao lanc,amento.

  Nota:

   A Equipe de Engenharia de Release do FreeBSD tambem usa este repositorio
   para rastrear solicitac,oes de aprovac,ao pendentes que sao recebidas
   antes de iniciar varias compilac,oes durante o ciclo de release, que o
   Engenheiro de Release especifica o periodo de corte com um email para os
   desenvolvedores do FreeBSD.

   Dependendo do conjunto de codigo subjacente em questao, e do impacto geral
   que o conjunto de codigo tem no FreeBSD como um todo, tais solicitac,oes
   podem ser aprovadas ou negadas pela Equipe de Engenharia de Release do
   FreeBSD.

   O mesmo se aplica `as extensoes de trabalho em andamento. Por exemplo, o
   trabalho em andamento para um novo driver de dispositivo que de outra
   forma e isolado do restante da arvore pode receber uma extensao. Um novo
   scheduler, no entanto, pode nao ser viavel, especialmente se tais
   mudanc,as dramaticas nao existirem em outra branch.

   O cronograma tambem e adicionado ao site do projeto, no repositorio doc,
   em head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. Este arquivo e
   continuamente atualizado conforme o ciclo progride.

  Nota:

   Na maioria dos casos, o schedule.xml pode ser copiado de uma versao
   anterior e atualizado de acordo.

   Alem de adicionar o schedule.xml ao site, o head/share/xml/navibar.ent e o
   head/share/xml/release.ent tambem sao atualizados para adicionar o link
   para o cronograma em varias subpaginas, bem como para habilitar o link
   para o cronograma na pagina principal do website do projeto.

   O cronograma tambem chamado a partir de
   head/en_US.ISO8859-1/htdocs/releng/index.xml.

   Aproximadamente um mes 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 compilac,oes do ciclo de release estejam
   disponiveis, atualize a entidade beta.local.where em
   head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. substituindo
   IGNORE por INCLUDE.

  Nota:

   Se dois ciclos de lanc,amento paralelo estao acontecendo ao mesmo tempo, a
   entidade beta2.local.where pode ser usada no lugar.

3. Terminologia da Engenharia de Release

   Esta sec,ao descreve algumas das terminologias usadas no restante deste
   documento.

  3.1. O Code Slush

   Embora o code slush nao seja um congelamento mandatorio da arvore, a
   Equipe de Engenharia de Release do FreeBSD solicita que resoluc,oes dos
   bugs existentes no codigo tenham prioridade sobre implementac,ao de novos
   recursos.

   O code slush nao impoe aprovac,oes de confirmac,ao para o Branch.

  3.2. O Code Freeze

   O code freeze marca o momento em que todos os commits para a branch exigem
   aprovac,ao explicita da Equipe de Engenharia de Release do FreeBSD.

   O repositorio Subversion do FreeBSD contem varios ganchos para executar
   verificac,oes de integridade antes que qualquer commit seja realmente
   confirmado na arvore. Um desses ganchos avaliara se o comprometimento com
   uma branch especifica requer aprovac,ao especifica.

   Para impor aprovac,oes de commit pela Equipe de Engenharia de Release do
   FreeBSD, o Engenheiro de Release atualiza o base/svnadmin/conf/approvers,
   e aplica a mudanc,a de volta para o repositorio. Feito isso, qualquer
   alterac,ao na branch deve incluir uma linha "Aprovado por:" na mensagem de
   commit.

   A linha "Aprovada por:" deve corresponder `a segunda coluna em
   base/svnadmin/conf/aprovovers , caso contrario, o commit sera rejeitado
   pelos hooks do repositorio.

  Nota:

   Durante o code freeze, os committers do FreeBSD devem seguir as
   Recomendac,oes de Requisic,ao de Mudanc,as.

  3.3. O KBI / Congelamento KPI

   A estabilidade de KBI/KPI implica que o caller (que faz uma chamada) de
   uma func,ao atraves de duas versoes diferentes de software que implementam
   a func,ao, resulta no mesmo estado final. O caller, seja um processo,
   thread ou func,ao, espera que a func,ao opere de uma determinada maneira,
   caso contrario, a estabilidade do KBI/KPI na branch e interrompida.

4. Alterac,oes na Pagina Web Durante o Ciclo de Release

   Esta sec,ao descreve as alterac,oes no site que devem ocorrer conforme o
   ciclo de lanc,amento progride.

  Nota:

   Os arquivos especificados ao longo desta sec,ao sao relativos `a branch
   head/ do repositorio doc no Subversion.

  4.1. Alterac,oes na Pagina Web Antes do Inicio do Ciclo de Release

   Quando o cronograma do ciclo de release esta disponivel, esses arquivos
   precisam ser atualizados para habilitar varias 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  

  4.2. Alterac,oes na pagina web durante a fase BETA ou RC

   Ao fazer a transic,ao de PRERELEASE para BETA, esses arquivos precisam ser
   atualizados para ativar o bloco "Teste de ajuda" na pagina de download.
   Todos os arquivos sao relativos ao head/ no repositorio doc:

                    Arquivo para editar                      O que mudar      
                                                         Altere %             
   en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml    beta.local.where     
                                                         IGNORE para INCLUDE  
                                                         Atualize %           
   share/xml/release.ent                                 betarel.vers para    
                                                         BETA1                
                                                         Adicione uma entrada 
   share/xml/news.xml                                    anunciando a versao  
                                                         BETA                 
                                                         Adicione as novas    
   en_US.ISO8859-1/htdocs/security/advisory-template.txt BETA, RC ou RELEASE  
                                                         final ao modelo      
                                                         Adicione as novas    
   en_US.ISO8859-1/htdocs/security/errata-template.txt   BETA, RC ou RELEASE  
                                                         final ao modelo      

   Uma vez criada a branch releng/12.0/, os diversos documentos relacionados
   `a release precisam ser gerados e adicionados manualmente ao repositorio
   doc/.

   Dentro de release/doc, invoque make(1) para gerar as paginas errata.html,
   hardware.html, readme.html e relnotes.html, que sao entao adicionadas ao
   diretorio doc/head/en_US.ISO8859-1/htdocs/releases/XYR/, em que XY
   representa o numero da versao principal e da versao secundaria.

   A propriedade fbsd:nokeywords deve ser definido como on nos arquivos
   recem-adicionados para que os hooks de pre-commit permitam que eles sejam
   adicionados ao repositorio.

  Nota:

   Os documentos relevantes relacionados `a release existem no repositorio
   doc para FreeBSD 12.x e posterior.

  4.3. Mudanc,as nos ports durante as fases BETA, RC, e a versao RELEASE final

   Para cada compilac,ao durante o ciclo de release, os arquivos MANIFEST
   contendo o SHA256 dos varios conjuntos de distribuic,ao, como base.txz,
   kernel.txz, e assim por diante, sao adicionados ao port
   misc/freebsd-release-manifests. Isso permite outros utilitarios alem do
   bsdinstall(8), como ports-mgmt/poudriere, usem esses conjuntos de
   distribuic,ao com seguranc,a fornecendo um mecanismo atraves do qual os
   checksums possam ser verificados.

5. Releases a partir da branch head/

   Esta sec,ao descreve os procedimentos gerais do ciclo de release do
   FreeBSD na branch head.

  5.1. Compilac,oes "ALPHA" do FreeBSD

   Tendo aparecido primeiramente durante o ciclo de release do FreeBSD
   10.0-RELEASE, a noc,ao de compilac,oes de fases "ALPHA" foi introduzida.
   Ao contrario das compilac,oes BETA e RC, as compilac,oes desse novo
   estagio ALPHA nao fazem parte do cronograma de Release do FreeBSD.

   A ideia por tras das compilac,oes ALPHA e disponibilizar builds regulares
   fornecidas pelo FreeBSD antes da criac,ao da branch stable/.

   Os snapshots ALPHA do FreeBSD devem ser preparados aproximadamente uma vez
   por semana.

   Para a primeira compilac,ao ALPHA, o valor BRANCH em sys/conf/newvers.sh
   precisa ser alterado de CURRENT para ALPHA1. Para compilac,oes ALPHA
   subsequentes, incremente cada valor de ALPHAN em um.

   Veja Sec,ao 7, "Construindo a Midia de Instalac,ao do FreeBSD" para
   informac,oes sobre como construir as imagens ALPHA.

  5.2. Criando a branch stable/12/

   Ao criar a branch stable/, varias alterac,oes sao necessarias na nova
   branch stable/ e na branch head/. Os arquivos listados sao relativos ao
   repositorio 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, fac,a as seguintes
   edic,oes:

                     Arquivo para editar                              O que mudar        
                                                               Atualize a versao do      
stable/12/UPDATING                                             FreeBSD e remova o aviso  
                                                               sobre WITNESS             
                                                               #ifndef MALLOC_PRODUCTION 
stable/12/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h #define MALLOC_PRODUCTION 
                                                               #endif                    
stable/12/lib/clang/llvm.build.mk                              Remova o comentario       
                                                               -DNDEBUG                  
stable/12/sys/*/conf/GENERIC*                                  Remova o suporte de       
                                                               depurac,ao                
stable/12/sys/*/conf/MINIMAL                                   Remova o suporte de       
                                                               depurac,ao                
stable/12/release/release.conf.sample                          Atualize o SRCBRANCH      
stable/12/sys/*/conf/GENERIC-NODEBUG                           Remova essas              
                                                               configurac,oes do kernel  
stable/12/sys/arm/conf/std.arm*                                Remova as opc,oes de      
                                                               depurac,ao                
                                                               Atualize o valor de       
stable/12/sys/conf/newvers.sh                                  BRANCH para refletir      
                                                               BETA1                     
                                                               Mova REPRODUCIBLE_BUILD   
stable/12/share/mk/src.opts.mk                                 de __DEFAULT_NO_OPTIONS   
                                                               para                      
                                                               __DEFAULT_YES_OPTIONS     
                                                               Mova LLVM_ASSERTIONS de   
                                                               __DEFAULT_NO_OPTIONS para 
stable/12/share/mk/src.opts.mk                                 __DEFAULT_YES_OPTIONS     
                                                               (Apenas para FreeBSD 13.x 
                                                               e posterior)              
                                                               Defina o dumpdev de AUTO  
                                                               para NO (ele e            
stable/12/libexec/rc/rc.conf                                   configuravel via          
                                                               bsdinstall(8) para        
                                                               aqueles que o querem      
                                                               habilitado por padrao)    
stable/12/release/Makefile                                     Remova as entradas        
                                                               debug.witness.trace       

   Entao, na branch head/, que agora se tornara uma nova versao principal:

                Arquivo para editar                      O que mudar          
   head/UPDATING                                 Atualize a versao do FreeBSD 
                                                 Atualize o valor de BRANCH   
   head/sys/conf/newvers.sh                      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 sec,ao               
                                                 freebsd<versao>.h            
   head/lib/clang/llvm.build.mk                  Atualize o valor do          
                                                 OS_VERSION                   
   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    

6. Release a partir da branch stable/

   Esta sec,ao descreve os procedimentos gerais do ciclo de release do
   FreeBSD a partir de uma branch stable/.

  6.1. Code Slush da branch stable do FreeBSD

   Na preparac,ao para o code freeze em uma branch stable, varios arquivos
   precisam ser atualizados para refletir o ciclo de release que esta
   oficialmente em andamento. Esses arquivos sao todos relativos ao nivel
   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 LIB32CPUFLAGS              
                                        Adiciona uma nova entrada .ds para a  
   gnu/usr.bin/groff/tmac/mdoc.local.in versao do FreeBSD, e atualiza         
                                        doc-default-operating-system          
                                        (FreeBSD 11.x e anteriores apenas)    

   No repositorio doc, atualize tambem
   head/pt_BR.ISO8859-1/htdocs/releases/12.0R/Makefile.hardware, alternando o
   valor de _BRANCH para BETAX, RCX ou RELEASE, respectivamente.

  6.2. Builds BETA do FreeBSD

   Apos o code slush, a proxima fase do ciclo de release e o code freeze.
   Este e o ponto no qual todos os commits para a branch stable requerem
   aprovac,ao explicita da Equipe de Engenharia de Release do FreeBSD. Isto e
   reforc,ado por hooks de pre-commit no repositorio Subversion editando
   base/svnadmin/conf/approvers para incluir uma expressao regular que
   coincida com a branch stable/12/ para a release:

 ^/stable/12/    re
 ^/releng/12.0/  re

  Nota:

   Ha duas excec,oes gerais para exigir aprovac,ao de commit durante o ciclo
   de release. A primeira e qualquer alterac,ao que precise ser "committed"
   pelo Engenheiro de Release para continuar com o fluxo de trabalho diario
   do ciclo de lanc,amento, e a outra sao as correc,oes de seguranc,a que
   podem ocorrer durante o ciclo de lanc,amento.

   Quando o code freeze estiver em vigor, a proxima construc,ao da branch
   sera rotulada como BETA1. Isso e feito atualizando o valor de BRANCH em
   sys/conf/newvers.sh de PRERELEASE para BETA1.

   Feito isso, o primeiro conjunto de builds BETA e iniciado. Builds BETA
   subsequ:entes nao requerem atualizac,oes em nenhum arquivo diferente do
   sys/conf/newvers.sh, incrementando o numero de compilac,ao da versao BETA.

  6.3. Criando a branch releng/12.0/

   Quando a primeira construc,ao RC (Release Candidate) esta pronta para
   comec,ar, a branch releng/ e criada. Este e um processo de varias etapas
   que deve ser feito em uma ordem especifica, a fim de evitar anomalias,
   como sobreposic,oes com valores de __ FreeBSD_version, por exemplo. Os
   caminhos listados abaixo sao relativos ao repositorio raiz. A ordem dos
   commits e o que mudar sao:

 % 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             
                                                  Substitua latest por        
   releng/12.0/etc/pkg/FreeBSD.conf               quarterly (trimestral) como 
                                                  a localizac,ao padrao do    
                                                  repositorio de pacotes      
                                                  Substitua latest por        
   releng/12.0/release/pkg_repos/release-dvd.conf quarterly (trimestral) como 
                                                  a localizac,ao padrao do    
                                                  repositorio de pacotes      
   stable/12/sys/conf/newvers.sh                  Atualize BETAX para         
                                                  PRERELEASE                  
   stable/12/sys/sys/param.h                      Atualize o __               
                                                  FreeBSD_version             
                                                  Adicione uma nova linha de  
   svnadmin/conf/approvers                        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, tambem
   atualize head/pt_BR.ISO8859-1/books/porters-handbook/versions/chapter.xml
   no repositorio do Projeto de Documentac,ao.

   Depois que a primeira compilac,ao de um RC estiver concluida 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 `as
   versoes disponiveis no menu drop-down exibido no rastreador de bugs.

7. Construindo a Midia de Instalac,ao do FreeBSD

   Esta sec,ao descreve os procedimentos gerais de produc,ao de snapshots e
   releases de desenvolvimento do FreeBSD.

  7.1. Scripts para compilac,ao de Releases

   Esta sec,ao descreve os scripts de build usados pela Equipe de Engenharia
   de Release do FreeBSD para produzir snapshots da versao em desenvolvimento
   e das releases.

    7.1.1. O script release.sh

   Antes do FreeBSD 9.0-RELEASE, o src/release/Makefile era atualizado para
   suportar o bsdinstall(8), e o script src/release/generate-release.sh foi
   introduzido como um wrapper para automatizar a chamada dos targets
   release(7).

   Antes do FreeBSD 9.2-RELEASE, foi introduzido o src/release/release.sh,
   que baseado fortemente em src/release/generate-release.sh incluia suporte
   para especificar arquivos de configurac,ao para substituir varias opc,oes
   e variaveis de ambiente. O suporte para arquivos de configurac,ao forneceu
   suporte para cross building (compilac,ao para mais de uma arquitetura) de
   uma release para cada arquitetura, especificando um arquivo de
   configurac,ao separado para cada chamada.

   Como um breve exemplo do uso de src/release/release.sh para construir uma
   unica versao em /scratch:

 # /bin/sh /usr/src/release/release.sh

   Como um breve exemplo do uso de src/release/release.sh para construir uma
   unica versao cross-build (entre arquiteturas) usando um diretorio 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 release(7) e src/release/release.conf.sample para mais detalhes e
   exemplos de uso.

    7.1.2. O Script Wrapper thermite.sh

   Para tornar o cross building do conjunto completo de arquiteturas
   suportadas em uma determinada branch mais rapido, mais facil e reduzindo
   os fatores de erro humano, um script wrapper de apoio ao
   src/release/release.sh foi escrito para iterar pelas varias combinac,oes
   de arquiteturas e chamar o script src/release/release.sh usando um arquivo
   de configurac,ao especifico para essa arquitetura.

   O script wrapper e chamado de thermite.sh, o qual esta disponivel no
   repositorio Subversion do FreeBSD em
   svn://svn.freebsd.org/base/user/gjb/thermite/ , alem dos arquivos de
   configurac,ao usados para construir os snapshots de desenvolvimento head/
   e stable/12/.

   O uso do thermite.sh e explicado em Sec,ao 7.2, "Construindo Snapshots de
   Desenvolvimento do FreeBSD" e Sec,ao 7.3, "Construindo Releases do
   FreeBSD".

   Cada arquitetura e kernel individual tem seu proprio arquivo de
   configurac,ao usado pelo release.sh. Cada branch tem sua propria
   configurac,ao defaults-X.conf que contem entradas comuns em cada
   arquitetura, onde substituic,oes ou variaveis especiais sao definidas e/ou
   substituidas nos arquivos por compilac,ao.

   O esquema de nomenclatura do arquivo de configurac,ao por compilac,ao esta
   na forma de ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, em que as
   variaveis em maiusculas sao equivalentes a que make(1) usa no sistema de
   compilac,ao e as variaveis minusculas sao definidas nos arquivos de
   configurac,ao, mapeando para a versao principal da respectiva branch.

   Cada branch tambem possui sua propria configurac,ao builds-X.conf, que e
   usada pelo thermite.sh. O script thermite.sh itera atraves de cada valor
   ${revision}, ${TARGET_ARCH}, ${KERNCONF} e ${type}, criando uma lista
   principal do que construir. No entanto, uma determinada combinac,ao da
   lista so sera criada se o respectivo arquivo de configurac,ao existir, que
   e onde o esquema de nomenclatura acima e 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
       chroot(8) de compilac,ao

  Nota:

   Os arquivos de configurac,ao builds-12.conf, defaults-12.conf, e main.conf
   existem para reduzir a repetic,ao entre os varios arquivos por
   compilac,ao.

  7.2. Construindo Snapshots de Desenvolvimento do FreeBSD

   As maquinas oficiais de compilac,ao de versoes tem um layout do sistema de
   arquivos especifico, que utiliza ZFS, o thermite.sh tira grande proveito
   de clones e snapshots, garantindo um ambiente de compilac,ao uniforme e
   consistente.

   Os scripts de compilac,ao localizam-se respectivamente em
   /releng/scripts-snapshot/scripts ou /releng/scripts-release/scripts, para
   evitar colisoes entre uma compilac,ao 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
   compilac,ao, /snap/ftp. Este diretorio contem diretorios de snapshots e
   releases. Eles sao usados apenas se a variavel EVERYTHINGISFINE estiver
   definida em main.conf.

  Nota:

   O nome da variavel EVERYTHINGISFINE foi escolhido para evitar a colisao
   com uma variavel possivelmente definida no ambiente do usuario, ativando
   acidentalmente o comportamento que depende de sua definic,ao.

   Como o thermite.sh percorre a lista principal de combinac,oes e localiza o
   arquivo de configurac,ao por compilac,ao, um dataset ZFS e criado sob o
   /releng, tal como /releng/12-amd64-GENERIC-snap. O checkout das arvores
   src/, ports/ e doc/ e realizado em diferentes datasets ZFS, tal como
   /releng/12-src-snap, os quais sao entao clonados e montados nos
   respectivos datasets de compilac,ao. Isso e feito para evitar a remoc,ao
   de uma determinada arvore 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-cleanup.sh -c ./builds-12.conf
 # ./thermite.sh -c ./builds-12.conf

   Quando as compilac,oes forem concluidas, scripts adicionais auxiliares
   estarao disponiveis para gerar e-mails de snapshots de desenvolvimento que
   sao 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

  Nota:

   A saida gerada deve ser checada duas vezes para garantir a exatidao, e o
   proprio e-mail deve ter assinatura PGP, in-line (no arquivo).

  Nota:

   Esses scripts auxiliares aplicam-se apenas `as compilac,oes de snapshot
   (versao instantanea) de desenvolvimento. Os anuncios durante o ciclo de
   lanc,amento (excluindo o anuncio de versao final) sao criados a partir de
   um modelo de email. Uma amostra do modelo de email usado atualmente pode
   ser encontrada aqui.

  7.3. Construindo Releases do FreeBSD

   Similar a compilac,ao de snapshots de desenvolvimento do FreeBSD, o
   thermite.sh seria invocado da mesma maneira. A diferenc,a entre snapshots
   de desenvolvimento e builds de releases, BETA e RC inclusos, e que os
   arquivos de configurac,ao do chroot(8) devem ser nomeados com release ao
   inves de snap no "type", como mencionado acima.

   Alem 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, tambem ajuste estaticamente
   o BUILDSVNREV para a revisao na branch refletindo a mudanc,a de nome,
   BUILDDATE para a data em que as compilac,oes sao iniciadas no formato
   YYYYMMDD. Se as arvores doc/ e ports/ tiverem sido marcadas, defina tambem
   o PORTBRANCH e o DOCBRANCH para o caminho da tag relevante no repositorio
   Subversion, substituindo HEAD pela ultima revisao alterada. Tambem defina
   releasesrc em builds-12.conf para a branch relevante, como stable/12/ ou
   releng/12.0/.

   Durante o ciclo de release, uma copia do CHECKSUM.SHA512 e do
   CHECKSUM.SHA256 para cada arquitetura e armazenada no repositorio interno
   da Equipe de Engenharia de Release do FreeBSD, alem de ser incluida nos
   diversos e-mails de anuncio. Cada MANIFEST contendo os hashes do base.txz,
   do kernel.txz, etc. tambem sao adicionados ao
   misc/freebsd-release-manifests na colec,ao de ports.

   Na preparac,ao para a compilac,ao da release, varios arquivos precisam ser
   atualizados:

      Arquivo para editar                      O que mudar                    
   sys/conf/newvers.sh       Atualize o valor BRANCH para RELEASE             
   UPDATING                  Adicione a data prevista do anuncio              
   lib/csu/common/crtbrand.c Altere __FreeBSD_version com o valor em          
                             sys/sys/param.h                                  

   Depois de construir a RELEASE final, a branch releng/12.0/ e marcada como
   release/12.0.0/ usando a revisao a partir da qual a RELEASE foi
   construida. Semelhante a criar as branches stable/12/ e releng/12.0/, isso
   e feito com svn cp. Da raiz do repositorio:

 % svn cp ^/releng/12.0/@r306420 release/12.0.0/
 % svn commit release/12.0.0/

8. Publicando a Midia de Instalac,ao do FreeBSD nos Espelhos do Projeto

   Esta sec,ao descreve o procedimento para publicar snapshots e releases de
   desenvolvimento do FreeBSD nos espelhos do Projeto.

  8.1. Preparando Imagens de Midias de Instalac,ao do FreeBSD

   A preparac,ao dos snapshots e das versoes do FreeBSD e um processo de duas
   partes:

     * Criando a estrutura de diretorios para corresponder a hierarquia em
       ftp-master

       Se EVERYTHINGISFINE for definido nos arquivos de configurac,ao de
       compilac,ao, main.conf no caso dos scripts de compilac,ao mencionados
       acima, isto acontece automaticamente no chroot(8) apos a compilac,ao
       ser concluida, criando a estrutura de diretorio em
       ${DESTDIR}/R/ftp-stage com um estrutura de caminho que corresponde ao
       que e esperado em ftp-master. Isto e 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 e compilada, o thermite.sh ira fazer um
       rsync do ${DESTDIR}/R/ftp-stage da compilac,ao chroot(8) para o
       diretorio /snap/ftp/snapshots ou /snap/ftp/releases no host de
       compilac,ao, respectivamente.

     * Copiando os arquivos para um diretorio temporario em ftp-master antes
       de mover os arquivos para pub/ para iniciar a propagac,ao para os
       servidores espelhos do Projeto

       Uma vez que todas as compilac,oes terminarem, /snap/ftp/snapshots, ou
       /snap/ftp/releases para uma versao, e pesquisado pelo ftp-master
       usando rsync para /archive/tmp/snapshots ou /archive/tmp/releases,
       respectivamente.

  Nota:

       No ftp-master na infraestrutura do Projeto FreeBSD, esta etapa requer
       acesso ao nivel de root, ja que esta etapa deve ser executada como o
       usuario archive.

  8.2. Publicando a Midia de Instalac,ao do FreeBSD

   Uma vez que as imagens sao colocadas em /archive/tmp/, elas estao prontas
   para serem publicadas colocando-as em /archive/pub/FreeBSD. Para reduzir o
   tempo de propagac,ao, o pax(1) e usado para criar links fisicos a partir
   de /archive/tmp para /archive/pub/FreeBSD.

  Nota:

   Para que isto seja efetivo, tanto o /archive/tmp quanto o /archive/pub
   devem residir no mesmo sistema de arquivos logico.

   Ha uma ressalva, no entanto, em que o rsync deve ser usado apos o pax(1)
   para corrigir os links simbolicos no pub/FreeBSD/snapshots/ISO-IMAGES que
   o pax(1) ira substituir por um hard link, aumentando o tempo de
   propagac,ao.

  Nota:

   Assim como nas etapas de preparac,ao, isto requer acesso em nivel de root,
   ja que essa etapa deve ser executada como o usuario archive.

   Como o usuario 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.

9. Encerrando o Ciclo de Release

   Esta sec,ao descreve as tarefas gerais de pos-release.

  9.1. Avisos de Erratas de Pos-Release

   A medida que o ciclo de release se aproxima da conclusao, e comum ter
   varios candidatos a EN (Aviso de Erratas) para abordar os problemas que
   foram descobertos ao final do ciclo. Apos o lanc,amento, a Equipe de
   Engenharia de Release do FreeBSD e a Equipe de Seguranc,a do FreeBSD
   reveem mudanc,as que nao foram aprovadas antes da versao final, e
   dependendo do escopo da mudanc,a em questao, podem emitir um EN.

  Nota:

   O processo atual de emissao de ENs e tratado pela Equipe de Seguranc,a do
   FreeBSD.

   Para solicitar uma Errata apos a conclusao de um ciclo de lanc,amento, o
   desenvolvedor deve preencher o Template de Errata>, em particular as
   sec,oes Background, Problem Description, Impact e, se aplicavel, as
   sec,oes Workaround.

   O modelo de Errata preenchido deve ser enviado por e-mail juntamente com
   um patch na branch releng/ ou uma lista de revisoes da branch stable/.

   Para pedidos de Errata imediatamente apos o lanc,amento, o pedido deve ser
   enviado por e-mail `a Equipe de Engenharia de Releases do FreeBSD e `a
   Equipe de Seguranc,a do FreeBSD. Depois que a branch releng/ foi entregue
   `a equipe de Seguranc,a do FreeBSD, conforme descrito em Sec,ao 9.2,
   "Entrega para a Equipe de Seguranc,a do FreeBSD", as solicitac,oes de
   Errata devem ser enviadas `a equipe de Seguranc,a do FreeBSD.

  9.2. Entrega para a Equipe de Seguranc,a do FreeBSD

   Aproximadamente duas semanas apos o lanc,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/.

10. Fim de Vida (End-of-Life) de Releases

   Esta sec,ao descreve os arquivos relacionados ao website que precisam ser
   atualizados quando uma release atingir o EoL (End-of-Life).

  10.1. Atualizac,oes do Website para End-of-Life

   Quando uma release atinge o End-of-Life, as referencias para essa release
   precisam ser removidas ou atualizadas no website:

                           Arquivo                               O que mudar     
                                                             Remover referencias 
  head/en_US.ISO8859-1/htdocs/index.xsl                      &u.relXXX.announce; 
                                                             e                   
                                                             &u.relXXX.current;. 
                                                             Mova as macros      
                                                             &u.relXXX.*; da     
  head/en_US.ISO8859-1/htdocs/releases/index.xml             lista de releases   
                                                             suportadas para a   
                                                             lista de Releases   
                                                             Legadas.            
                                                             Atualizar a branch  
                                                             releng em questao   
  head/en_US.ISO8859-1/htdocs/releng/index.xml               para refletir que a 
                                                             branch nao e mais   
                                                             suportada.          
                                                             Remover a branch da 
  head/en_US.ISO8859-1/htdocs/security/security.xml          lista de branchs    
                                                             suportadas.         
  head/en_US.ISO8859-1/htdocs/where.xml                      Remover as URLs da  
                                                             release.            
                                                             Remover referencias 
  head/share/xml/navibar.ent                                 &u.relXXX.announce; 
                                                             e                   
                                                             &u.relXXX.current;. 
                                                             Remover referencias 
  head/en_US.ISO8859-1/htdocs/security/advisory-template.txt da release e releng 
                                                             branch.             
                                                             Remover referencias 
  head/en_US.ISO8859-1/htdocs/security/errata-template.txt   da release e releng 
                                                             branch.             
