                        Engenharia de Release do FreeBSD

  Murray Stokely

       <murray@FreeBSD.org>
       https://people.FreeBSD.org/~murray/
     

   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.

   2018-09-21 03:22:51 +0000 por Edson Brandi.
   Resumo

  Nota:

   Este documento esta desatualizado e nao descreve com precisao os
   procedimentos atuais de lanc,amentos da equipe de Engenharia de Release
   (Versao) do FreeBSD. E retido para fins historicos. Os procedimentos
   atuais usados pela equipe de Engenharia de Release do FreeBSD estao
   disponiveis no artigo Engenharia de Release do FreeBSD.

   Este artigo descreve a abordagem usada pela equipe de engenharia de
   release do FreeBSD para produzir versoes do Sistema Operacional FreeBSD
   com qualidade de produc,ao. Ele detalha a metodologia utilizada para as
   versoes oficiais do FreeBSD e descreve as ferramentas disponiveis para
   aqueles interessados em produzir versoes customizadas do FreeBSD para uso
   corporativo ou para uso em produtos comerciais.

   [ Documento HTML em partes / Documento HTML completo ]

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

   Indice

   1. Introduc,ao

   2. Processos de Release (Versao)

   3. Construc,ao da Release (Versao)

   4. Distribuic,ao

   5. Extensibilidade

   6. Lic,oes Aprendidas do FreeBSD 4.4

   7. Direc,oes futuras

   8. Agradecimentos

1. Introduc,ao

   O desenvolvimento do FreeBSD e um processo muito aberto. O FreeBSD e
   composto por contribuic,oes de milhares de pessoas em todo o mundo. O
   Projeto FreeBSD fornece acesso ao Subversion [1] para o publico em geral
   para que outros possam ter acesso a mensagens de log, diffs (patches)
   entre branches (ramificac,oes) de desenvolvimento e outros aprimoramentos
   de produtividade que o gerenciamento formal de codigo-fonte proporciona.
   Isso tem sido uma grande ajuda na atrac,ao de desenvolvedores talentosos
   para o FreeBSD. No entanto, acho que todos concordariam que o caos logo se
   manifestaria se o acesso para modificar o repositorio principal fosse
   aberto a todos na Internet. Dessa forma, apenas um grupo "seleto" de quase
   300 pessoas recebe acesso de escrita ao repositorio do Subversion. Estes
   committers [2] sao normalmente as pessoas que fazem a maior parte do
   desenvolvimento do FreeBSD. Um Core team [3] eleito fornece algum nivel de
   orientac,ao sobre o projeto.

   O ritmo acelerado de desenvolvimento do FreeBSD torna a principal branch
   de desenvolvimento inadequada para o uso diario pelo publico em geral. Em
   particular, sao necessarios esforc,os de estabilizac,ao para polir o
   sistema de desenvolvimento em uma release de qualidade apropriada para uso
   em ambiente produtivo. Para resolver este conflito, o desenvolvimento
   continua em varias trilhas paralelas. A principal branch de
   desenvolvimento e a HEAD ou trunk da nossa arvore do Subversion, conhecida
   como "FreeBSD-CURRENT" ou "-CURRENT" quando abreviado.

   Um conjunto de branches mais estaveis e mantido, e e conhecido como
   "FreeBSD-STABLE" ou "-STABLE" na forma abreviada. Todas as branchs ficam
   em um repositorio principal do Subversion mantido pelo Projeto FreeBSD. O
   FreeBSD-CURRENT e a "vanguarda do desenvolvimento tecnologico" do FreeBSD,
   pelo qual todas as novas alterac,oes entram no sistema pela primeira vez.
   O FreeBSD-STABLE e a branch de desenvolvimento a partir do qual as
   releases principais sao feitas. Mudanc,as entram nesta branch em um ritmo
   diferente, e com a suposic,ao geral de que elas foram primeiro para o
   FreeBSD-CURRENT e foram exaustivamente testadas por nossa comunidade de
   usuarios.

   O termo stable no nome da branch refere-se `a estabilidade presumida da
   Interface Binaria da Aplicac,ao (ABI), que e prometida pelo projeto. Isso
   significa que um aplicativo de usuario compilado em uma versao mais antiga
   do sistema da mesma branch funciona em um sistema mais novo da mesma
   branch. A estabilidade do ABI melhorou muito em relac,ao `as versoes
   anteriores. Na maioria dos casos, os binarios dos sistemas STABLE mais
   antigos sao executados sem modificac,oes em sistemas mais recentes,
   incluindo o HEAD, assumindo que as interfaces de gerenciamento do sistema
   nao sao usadas.

   No periodo intermediario entre as versoes, snapshots semanais sao
   construidos automaticamente pelas maquinas de build do Projeto FreeBSD e
   disponibilizados para download em
   ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. A ampla disponibilidade de
   snapshots binarios e a tendencia da nossa comunidade de usuarios para
   acompanhar o desenvolvimento do -STABLE com o Subversion e "make
   buildworld" [4] ajuda a manter o FreeBSD-STABLE em uma condic,ao muito
   confiavel, mesmo antes que as atividades de garantia de qualidade aumentem
   na proximidade de um grande lanc,amento.

   Alem dos snapshots de instalac,ao no formato ISO, imagens semanais de
   maquinas virtuais tambem sao fornecidas para uso com o VirtualBox, o qemu
   ou outros softwares populares de emulac,ao. As imagens de maquinas
   virtuais podem ser baixadas em
   ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/.

   As imagens das maquinas virtuais tem aproximadamente 150MB compactadas com
   o xz(1) e contem um sistema de arquivos esparso de 10GB quando atachado a
   uma maquina virtual.

   Relatorios de bugs e solicitac,oes de recursos sao enviados continuamente
   pelos usuarios durante todo o ciclo da release. Os relatorios de problemas
   sao inseridos em nosso banco de dados do Bugzilla por meio da interface da
   Web disponibilizada em https://www.freebsd.org/support/bugreports.html.

   Para atender nossos usuarios mais conservadores, versoes individuais foram
   introduzidas com o FreeBSD 4.3. Estas branchs de versoes sao criadas pouco
   antes de uma liberac,ao final ser feita. Apos o lanc,amento, somente as
   correc,oes e adic,oes de seguranc,a mais criticas sao aplicadas na branch
   da versao. Alem das atualizac,oes do codigo fonte via Subversion,
   patchkits binarios estao disponiveis para manter os sistemas nas branchs
   releng/X.Y atualizadas.

  1.1. O que Este Artigo Descreve

   As sec,oes a seguir deste artigo descrevem:

   Sec,ao 2, "Processos de Release (Versao) "

           As diferentes fases do processo de engenharia de release que levam
           `a criac,ao do sistema atual.

   Sec,ao 3, "Construc,ao da Release (Versao)"

           O processo de criac,ao atual.

   Sec,ao 5, "Extensibilidade"

           Como o release base pode ser estendido por terceiros.

   Sec,ao 6, "Lic,oes Aprendidas do FreeBSD 4.4"

           Algumas das lic,oes aprendidas atraves do lanc,amento do FreeBSD
           4.4.

   Sec,ao 7, "Direc,oes futuras"

           Direc,oes futuras de desenvolvimento.

2. Processos de Release (Versao)

   Novas versoes do FreeBSD sao liberadas a partir da branch -STABLE em
   intervalos de aproximadamente quatro meses. O processo de release do
   FreeBSD comec,a a se desenhar cerca de 70-80 dias antes da data de
   lanc,amento prevista, quando o engenheiro de versao envia um email para as
   listas de discussao de desenvolvimento para lembrar aos desenvolvedores
   que eles so tem 15 dias para integrar novas alterac,oes antes do
   congelamento de codigo. Durante esse tempo, muitos desenvolvedores
   executam o que ficou conhecido como "MFC sweeps".

   MFC significa "Merge From CURRENT" e descreve o processo de fusao de uma
   alterac,ao testada de nossa branch de desenvolvimento -CURRENT com a nossa
   branch -STABLE. A politica do projeto requer que qualquer mudanc,a seja
   aplicada pela primeira vez ao trunk, e aplicada `as branches -STABLE apos
   testes externos suficientes serem feitos pelos usuarios no -CURRENT
   (espera-se que os desenvolvedores testem extensivamente a mudanc,a antes
   de enviarem a mesma para o -CURRENT, mas e impossivel para uma pessoa
   exercer todos os usos de um sistema operacional de proposito geral). O
   periodo minimo de MFC e de 3 dias, que normalmente e usado apenas para
   correc,oes de bugs triviais ou criticas.

  2.1. Revisao de codigo

   Sessenta dias antes do lanc,amento previsto, o repositorio de codigo entra
   um "congelamento de codigo". Durante esse tempo, todos os commits para a
   branch -STABLE devem ser aprovados pela equipe de engenharia de release
   (versao) <re@FreeBSD.org>. O processo de aprovac,ao e tecnicamente
   aplicado por um "pre-commit hook". Os tipos de alterac,oes permitidos
   durante esse periodo incluem:

     * Correc,oes de bugs.

     * Atualizac,oes de documentac,ao.

     * Correc,oes relacionadas `a seguranc,a de qualquer tipo.

     * Pequenas alterac,oes nos drivers de dispositivos, como a adic,ao de
       novos IDs de dispositivos.

     * Atualizac,oes de driver dos fornecedores.

     * Qualquer mudanc,a adicional que a equipe de engenharia de release
       julgue justificada, dado o risco potencial.

   Logo apos o inicio do congelamento de codigo, uma imagem BETA1 e criada e
   liberada para testes generalizados. Durante o congelamento de codigo, pelo
   menos uma imagem beta ou um candidato a versao e lanc,ado a cada duas
   semanas ate que a versao final esteja pronta. Durante os dias que
   antecedem a versao final, a equipe de engenharia de release esta em
   constante comunicac,ao com a equipe de seguranc,a, os mantenedores de
   documentac,ao e os mantenedores de ports para garantir que todos os
   diferentes componentes necessarios para uma versao bem-sucedida estejam
   disponiveis.

   Apos a qualidade das imagens BETA ser satisfatoria o suficiente, e nenhuma
   mudanc,a grande e potencialmente arriscada estar planejada, a branch
   release e criada e as imagens Release Candidate (RC) sao construidas a
   partir da branch release, ao inves das Imagens BETA serem construidas da
   branch STABLE. Alem disso, o congelamento na branch STABLE e suspenso e a
   branch de release entra em um "congelamento de codigo rigido", onde fica
   muito mais dificil justificar novas alterac,oes no sistema, a menos que
   envolva uma correc,ao seria de bug ou um problema de seguranc,a.

  2.2. Checklist Final para uma Release

   Quando varias imagens BETA ja tiverem sido disponibilizadas para testes
   generalizados e todos os principais problemas tiverem sido resolvidos, o
   "polimento" da versao final pode comec,ar.

    2.2.1. Criac,ao da Branch (Ramificac,ao) da Release (Versao)

  Nota:

   Em todos os exemplos abaixo, $FSVN refere-se ao local do repositorio
   Subversion do FreeBSD, svn+ssh://svn.FreeBSD.org/base/.

   O layout das branchs do FreeBSD no Subversion e descrito no Guia do
   Commiter. O primeiro passo na criac,ao de uma branch e identificar a
   revisao do codigo fonte do stable/X, a partir do qual voce deseja criar a
   nova branch.

 # svn log -v $FSVN/stable/9

   O proximo passo e criar a branch da release

 # svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2

   Esta branch pode ser obtida com:

 # svn co $FSVN/releng/9.2 src

  Nota:

   A criac,ao das tags da branch releng e de release e feita pela Equipe de
   Engenharia de Release.

                      Branch de Desenvolvimento do FreeBSD
                           Branch FreeBSD 3.x STABLE
                           Branch FreeBSD 4.x STABLE
                           Branch FreeBSD 5.x STABLE
                           Branch FreeBSD 6.x STABLE
                           Branch FreeBSD 7.x STABLE
                           Branch FreeBSD 8.x STABLE
                           Branch FreeBSD 9.x STABLE

    2.2.2. Incrementando o numero da versao

   Antes que a versao final possa ser marcada, construida e lanc,ada, os
   seguintes arquivos precisam ser modificados para refletir a versao correta
   do FreeBSD:

     * doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml

     * doc/en_US.ISO8859-1/books/porters-handbook/book.xml

     * doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi

     * ports/Tools/scripts/release/config

     * doc/share/xml/freebsd.ent

     * src/Makefile.inc1

     * src/UPDATING

     * src/gnu/usr.bin/groff/tmac/mdoc.local

     * src/release/Makefile

     * src/release/doc/en_US.ISO8859-1/share/xml/release.dsl

     * src/release/doc/share/examples/Makefile.relnotesng

     * src/release/doc/share/xml/release.ent

     * src/sys/conf/newvers.sh

     * src/sys/sys/param.h

     * src/usr.sbin/pkg_install/add/main.c

     * doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml

   As notas de versao e os arquivos de errata tambem precisam ser ajustados
   para a nova versao (na branch (ramificac,ao) da release) e truncados
   apropriadamente (na branch stable/current):

     * src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml

     * src/release/doc/en_US.ISO8859-1/errata/article.xml

   O Sysinstall deve ser atualizado para exibir o numero de ports disponiveis
   e a quantidade de espac,o em disco necessaria para a Colec,ao de Ports.
   [5] Esta informac,ao e atualmente mantida em
   src/usr.sbin/bsdinstall/dist.c.

   Apos a release ter sido construida, varios arquivos devem ser atualizados
   para anunciar a versao para o mundo. Esses arquivos sao relativos a head/
   dentro da arvore doc/ do subversion.

     * share/images/articles/releng/branches-relengX.pic

     * head/share/xml/release.ent

     * en_US.ISO8859-1/htdocs/releases/*

     * en_US.ISO8859-1/htdocs/releng/index.xml

     * share/xml/news.xml

   Alem disso, atualize o arquivo da "Arvore Genealogica do BSD":

     * src/share/misc/bsd-family-tree

    2.2.3. Criando a Tag de Release

   Quando a versao final estiver pronta, o seguinte comando criara a tag
   release/9.2.0.

 # svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0

   Os gerentes de Documentac,ao e do Ports sao responsaveis por marcar suas
   respectivas arvores com a tag tags/RELEASE_9_2_0.

   Quando o comando svn cp do Subversion e usado para criar uma tag de
   versao, isso identifica o codigo fonte em um ponto especifico no tempo.
   Criando tags, nos garantimos que futuros construtores de versoes sempre
   poderao usar exatamente o mesmo codigo fonte que usamos para criar as
   releases oficiais do Projeto FreeBSD.

3. Construc,ao da Release (Versao)

   As "releases" do FreeBSD podem ser construidas por qualquer pessoa com uma
   maquina rapida e acesso a um repositorio de codigo-fonte. (Isso deveria
   ser todo mundo, ja que oferecemos acesso ao Subversion! Veja a sec,ao
   sobre Subversion no Handbook para detalhes.) O unico requisito especial e
   que o dispositivo md(4) esteja disponivel. Se o dispositivo nao estiver
   carregado em seu kernel, entao o modulo do kernel deve ser carregado
   automaticamente quando o mdconfig(8) for executado durante a fase de
   criac,ao da midia de boot. Todas as ferramentas necessarias para construir
   uma release estao disponiveis no repositorio Subversion em src/release.
   Essas ferramentas visam fornecer uma maneira consistente de construir
   versoes do FreeBSD. Uma release completa pode ser construida com apenas um
   unico comando, incluindo a criac,ao de imagens ISO adequadas para
   gravac,ao em CD-ROM ou DVD e um diretorio para instalac,ao por FTP. A
   pagina de manual release(7) documenta completamente o script
   src/release/generate-release.sh que e usado para construir uma release. O
   generate-release.sh e um involucro em torno do target do Makefile: make
   release.

  3.1. Construindo uma Release (Versao)

   A pagina de manual release(7) documenta os comandos exatos necessarios
   para construir uma Release do FreeBSD. As seguintes sequencias de comandos
   podem construir uma versao 9.2.0:

 # cd /usr/src/release
 # sh generate-release.sh release/9.2.0 /local3/release

   Depois de executar esses comandos, todos os arquivos preparados da versao
   estarao disponiveis no diretorio /local3/release/R.

   O release Makefile pode ser dividido em varias etapas distintas.

     * Criac,ao de um ambiente de sistema limpo em uma hierarquia de
       diretorio separada com "make installworld".

     * Checkout do Subversion de uma versao limpa do codigo fonte do sistema,
       da documentac,ao e e da colec,ao de ports na hierarquia de build do
       release.

     * Popula o /etc e o /dev no ambiente chrooted (Processo de transferir o
       diretorio root para outro lugar).

     * Faz chroot na hierarquia de build (construc,ao) da release, para
       tornar mais dificil para o ambiente externo corromper essa
       construc,ao.

     * Execuc,ao do comando make world no ambiente chrooted.

     * Compilac,ao dos binarios relacionados ao Kerberos.

     * Compilac,ao do kernel GENERIC.

     * Criac,ao uma arvore de diretorios temporarios onde as distribuic,oes
       binarias serao compiladas e empacotadas.

     * Compilac,ao e instalac,ao do toolchain necessario para converter o
       fonte da documentac,ao (SGML) em HTML e demais documentos de texto que
       acompanharao a versao.

     * Compilac,ao e instalac,ao da documentac,ao propriamente dita (manuais
       do usuario, tutoriais, notas de versao, listas de compatibilidade de
       hardware e assim por diante).

     * Empacotamento dos tarballs de distribuic,ao dos binarios e fontes.

     * Criac,ao da hierarquia de instalac,ao por FTP.

     * (opcionalmente) Criac,ao das imagens ISO para midia de CDROM/DVD.

   Para obter maiores informac,oes sobre a infraestrutura de criac,ao de
   versoes, consulte release(7).

  Nota:

   E importante remover qualquer configurac,ao especifica do seu servidor do
   /etc/make.conf. Por exemplo, seria imprudente distribuir binarios que
   foram compilados em um sistema com CPUTYPE configurado para um processador
   especifico.

  3.2. Software Contribuido ("ports")

   A Colec,ao de Ports do FreeBSD e uma colec,ao de mais de 24.000 pacotes de
   software de terceiros disponiveis para o FreeBSD. A Equipe de
   Gerenciamento de Ports <portmgr@FreeBSD.org> e responsavel por manter uma
   arvore de ports consistente que pode ser usada para criar os pacotes
   binarios que acompanham as releases oficiais do FreeBSD.

  3.3. ISOs das Releases (Versoes)

   Comec,ando no FreeBSD 4.4, o Projeto FreeBSD decidiu liberar todas as
   quatro imagens ISO que eram vendidas anteriormente nas distribuic,oes
   "oficiais" em CDROM pela BSRi/Wind River Systems/FreeBSD Mall. Cada um dos
   quatro discos deve conter um arquivo README.TXT que explica o conteudo do
   disco, um arquivo CDROM.INF que fornece metadados do disco para que o
   bsdinstall(8) possa validar e usar o conteudo, e um arquivo filename.txt
   que fornece um manifesto para o disco. Este manifesto pode ser criado com
   um simples comando:

 /stage/cdrom# find . -type f | sed -e 's/^\.\///' | sort > filename.txt

   Os requisitos especificos de cada CD sao descritos abaixo.

    3.3.1. Disco 1

   O primeiro disco e quase completamente criado por make release. As unicas
   alterac,oes que devem ser feitas no diretorio disc1 sao a adic,ao de um
   diretorio tools e tantos pacotes de software de terceiros quanto couberem
   no disco. O diretorio tools contem software que permite aos usuarios criar
   disquetes de instalac,ao a partir de outros sistemas operacionais. Esse
   disco deve ser inicializado para que os usuarios dos PCs modernos nao
   precisem criar disquetes de instalac,ao.

   Se um kernel customizado do FreeBSD precisa ser incluido, entao o
   bsdinstall(8) e o release(7) deve ser atualizado para incluir instruc,oes
   de instalac,ao. O codigo relevante esta contido em src/release e
   src/usr.sbin/bsdinstall. Especificamente, os arquivos
   src/release/Makefile, dist.c, dist.h, menus.c , install.c, e Makefile
   precisarao ser atualizados em src/usr.sbin/bsdinstall. Opcionalmente, voce
   pode escolher atualizar o bsdinstall.8.

    3.3.2. Disco 2

   O segundo disco tambem e largamente criado por make release. Este disco
   contem um "live filesystem" que pode ser usado por bsdinstall(8) para
   solucionar problemas de instalac,ao do FreeBSD. Este disco deve ser
   inicializavel e tambem deve conter uma copia compactada do repositorio CVS
   no diretorio CVSROOT e demos de software comercial no diretorio commerce.

    3.3.3. Suporte para varios volumes

   O Sysinstall suporta a instalac,ao de pacotes a partir de varios volumes.
   Isso requer que cada disco tenha um arquivo INDEX contendo todos os
   pacotes em todos os volumes de um conjunto, junto com um campo extra que
   indica em qual volume esse pacote especifico esta. Cada volume no conjunto
   tambem deve ter a variavel CD_VOLUME definida no arquivo cdrom.inf para
   que o bsdinstall possa informar qual volume e qual. Quando um usuario
   tentar instalar um pacote que nao esteja no disco atual, o bsdinstall
   solicitara que o usuario insira o disco apropriado.

4. Distribuic,ao

  4.1. Sites FTP

   Quando a release for totalmente testada e empacotada para distribuic,ao, o
   site FTP principal devera ser atualizado. Os sites de FTP publicos
   oficiais do FreeBSD sao todos espelhos de um servidor principal que esta
   acessivel somente a outros sites FTP. Este site e conhecido como
   ftp-master. Quando a release estiver pronta, os seguintes arquivos devem
   ser modificados no ftp-master:

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/

           O diretorio FTP instalavel como saida de make release.

   /pub/FreeBSD/ports/arch/packages-X.Y-release/

           O pacote completo criado para esta versao.

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools

           Um link simbolico para ../../../tools.

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages

           Um link simbolico para ../../../ports/arch/packages-X.Y-release.

   /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso

           As imagens ISO. O "*" e o disc1, disc2 , etc. Somente se houver um
           disc1 e houver um CD alternativo para o primeiro disco de
           instalac,ao (por exemplo, uma instalac,ao simplificada sem sistema
           de janelas) tambem pode haver um mini.

   Para mais informac,oes sobre a arquitetura do sistema de espelhamento dos
   sites de FTP para distribuic,ao do FreeBSD, por favor veja o artigo
   Espelhando o FreeBSD.

   Pode levar de muitas horas a dois dias apos a atualizac,ao do ftp-master
   antes que a maioria dos sites de FTP da camada 1 tenham o novo software,
   dependendo se um conjunto de pacotes foi ou nao carregado ao mesmo tempo.
   E imperativo que os engenheiros de release coordenem com os
   administradores dos sites espelho do FreeBSD antes de anunciar a
   disponibilidade geral de novo software nos sites FTP. Idealmente, o pacote
   da release deve ser carregado pelo menos quatro dias antes do dia de
   lanc,amento. Os bits da release devem ser carregados entre 24 e 48 horas
   antes do horario de lanc,amento planejado com as permissoes de arquivo
   "other" desativadas. Isso permitira que os sites espelho fac,am o
   download, mas o publico em geral nao podera baixa-los dos sites espelho.
   Um e-mail deve ser enviado para a lista dos administradores do site
   espelho do FreeBSD no momento em que os bits da release forem publicados,
   informando que a release foi preparada e informando o horario em que os
   sites espelho devem comec,ar a permitir o acesso. Certifique-se de incluir
   um fuso horario com a hora, por exemplo, torna-lo relativo ao GMT.

  4.2. Replicac,ao do CD-ROM

   Em breve: Dicas para enviar ISOs do FreeBSD para um replicador e medidas
   de garantia de qualidade a serem tomadas.

5. Extensibilidade

   Embora o FreeBSD forme um sistema operacional completo, nao ha nada que
   force voce a usar o sistema exatamente como o empacotamos para
   distribuic,ao. Tentamos projetar o sistema para ser o mais extensivel
   possivel, de modo que ele possa servir como uma plataforma na qual outros
   produtos comerciais possam ser construidos. A unica "regra" que temos
   sobre isso e que se voce for distribuir o FreeBSD com mudanc,as nao
   triviais, nos encorajamos voce a documentar suas melhorias! A comunidade
   do FreeBSD so pode ajudar a suportar usuarios do software que fornecemos.
   Nos certamente encorajamos a inovac,ao na forma de ferramentas avanc,adas
   de instalac,ao e administrac,ao, por exemplo, mas voce nao esperar que
   respondamos perguntas sobre isso.

  5.1. Usando o script bsdinstall

   A ferramenta de instalac,ao e configurac,ao do sistema FreeBSD,
   bsdinstall(8), pode ser programada para fornecer instalac,oes
   automatizadas para sites grandes. Essa funcionalidade pode ser usada em
   conjunto com Intel(R) PXE [6] para inicializar sistemas da rede.

6. Lic,oes Aprendidas do FreeBSD 4.4

   O processo de engenharia de release do 4.4 comec,ou formalmente em 1-o de
   agosto de 2001. Apos essa data, todos os commits da branch RELENG_4 do
   FreeBSD tiveram que ser explicitamente aprovados pela Equipe de Engenharia
   de Release <re@FreeBSD.org>. O primeiro release candidate para a
   arquitetura x86 foi lanc,ado em 16 de agosto, seguido por mais 4
   candidatos a versao que antecederam a versao final em 18 de setembro. O
   agente de seguranc,a esteve muito envolvido na ultima semana do processo,
   pois varios problemas de seguranc,a foram encontrados nos candidatos
   anteriores. Um total de mais de 500 e-mails foram enviados para a Equipe
   de Engenharia de Release <re@FreeBSD.org> em pouco mais de um mes.

   Nossa comunidade de usuarios deixou bem claro que a seguranc,a e a
   estabilidade de uma versao do FreeBSD nao devem ser sacrificadas por
   quaisquer prazos auto-impostos ou datas-alvo de lanc,amento. O projeto
   FreeBSD cresceu tremendamente ao longo de sua existencia e a necessidade
   de procedimentos padronizados de engenharia de versoes nunca foi tao
   aparente. Isso se tornara ainda mais importante `a medida que o FreeBSD
   for portado para novas plataformas.

7. Direc,oes futuras

   E imperativo que nossas atividades de engenharia de release sejam
   escaladas com nossa crescente base de usuarios. Nessa linha, estamos
   trabalhando muito para documentar os procedimentos envolvidos na produc,ao
   de versoes do FreeBSD.

     * Paralelismo - Algumas partes da compilac,ao da release sao, na
       verdade, "embarac,osamente paralelas". A maioria das tarefas e muito
       intensiva em I/O, portanto, ter varias unidades de disco de alta
       velocidade e realmente mais importante do que usar varios
       processadores para acelerar o processo do make release. Se varios
       discos forem usados para hierarquias diferentes no ambiente chroot(2),
       o CVS checkout das arvores do ports e do doc podem estar acontecendo
       simultaneamente como o make world em outro disco. Usar uma soluc,ao
       RAID (hardware ou software) pode diminuir significativamente o tempo
       de compilac,ao geral.

     * Releases cross-building - Criac,ao do release IA-64 ou Alpha em
       hardware x86? Use o comando make TARGET=ia64 release.

     * Teste de regressao - Precisamos de melhores testes automatizados para
       o FreeBSD.

     * Ferramentas de instalac,ao - Nosso programa de instalac,ao ha muito
       tempo ultrapassou `a sua expectativa de vida util. Varios projetos
       estao em desenvolvimento para fornecer um mecanismo de instalac,ao
       mais avanc,ado. O projeto libh era um desses projetos que visava
       fornecer um novo e inteligente framework de pacotes e um programa de
       instalac,ao GUI.

8. Agradecimentos

   Eu gostaria de agradecer a Jordan Hubbard por me dar a oportunidade de
   assumir algumas das responsabilidades de engenharia de release do FreeBSD
   4.4 e tambem por todo o seu trabalho ao longo dos anos fazendo do FreeBSD
   o que e hoje. E claro quea Release nao teria sido possivel sem todo o
   trabalho relacionado a release feito por Satoshi Asami
   <asami@FreeBSD.org>, Steve Price <steve@FreeBSD.org>, Bruce A. Mah
   <bmah@FreeBSD.org>, Nik Clayton <nik@FreeBSD.org>, David O'Brien
   <obrien@FreeBSD.org>, Kris Kennaway <kris@FreeBSD.org>, John Baldwin
   <jhb@FreeBSD.org> e o resto da comunidade de desenvolvimento do FreeBSD.
   Eu tambem gostaria de agradecer a Rodney Grimes <rgrimes@FreeBSD.org>,
   Poul-Henning Kamp <phk@FreeBSD.org>, e outros que trabalharam nas
   ferramentas de engenharia de release nos primeiros dias do FreeBSD. Este
   artigo foi influenciado por documentos de engenharia de release do CSRG
   [7], o Projeto NetBSD, [8], e as notas de processo de engenharia de
   release propostas por John Baldwin. [9]

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

   [1] Subversion, http://subversion.apache.org

   [2] Committers do FreeBSD

   [3] Core Team do FreeBSD

   [4] Re-construindo o "mundo"

   [5] Colec,ao de Ports do FreeBSD https://www.FreeBSD.org/port

   [6] ../../../../doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html

   [7] Marshall Kirk McKusick, Michael J. Karels e Keith Bostic: A Engenharia
   de Release do 4.3BSD

   [8] Documentac,ao do desenvolvedor do NetBSD: Engenharia de Release
   http://www.NetBSD.org/developers/releng/index.html

   [9] Proposta de engenharia de Release do FreeBSD de John Baldwin
   https://people.FreeBSD.org/~jhb/docs/releng.txt
