---
title: Engenharia de Release do FreeBSD (Legado)
authors:
  - author: Murray Stokely
    email: murray@FreeBSD.org
    webpage: https://people.FreeBSD.org/~murray/
trademarks: ["freebsd", "intel", "general"]
---

= Engenharia de Release do FreeBSD (Legado)
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:images-path: articles/releng/

ifdef::env-beastie[]
ifdef::backend-html5[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
:imagesdir: ../../../images/{images-path}
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[.abstract-title]
Resumo

[NOTE]
====
Este documento está desatualizado e não descreve com precisão os procedimentos atuais de lançamentos da equipe de Engenharia de Release (Versão) do FreeBSD. É retido para fins históricos. Os procedimentos atuais usados pela equipe de Engenharia de Release do FreeBSD estão disponíveis no artigo extref:{freebsd-releng}[Engenharia de Release do FreeBSD].
====

Este artigo descreve a abordagem usada pela equipe de engenharia de release do FreeBSD para produzir versões do Sistema Operacional FreeBSD com qualidade de produção. Ele detalha a metodologia utilizada para as versões oficiais do FreeBSD e descreve as ferramentas disponíveis para aqueles interessados em produzir versões customizadas do FreeBSD para uso corporativo ou para uso em produtos comerciais.

'''

toc::[]

[[introduction]]
== Introdução

O desenvolvimento do FreeBSD é um processo muito aberto. O FreeBSD é composto por contribuições de milhares de pessoas em todo o mundo. O Projeto FreeBSD fornece acesso ao Subversion footnote:[Subversion, http://subversion.apache.org] para o público em geral para que outros possam ter acesso a mensagens de log, diffs (patches) entre branches (ramificações) de desenvolvimento e outros aprimoramentos de produtividade que o gerenciamento formal de código-fonte proporciona. Isso tem sido uma grande ajuda na atração de desenvolvedores talentosos para o FreeBSD. No entanto, acho que todos concordariam que o caos logo se manifestaria se o acesso para modificar o repositório principal fosse aberto a todos na Internet. Dessa forma, apenas um grupo "seleto" de quase 300 pessoas recebe acesso de escrita ao repositório do Subversion. Estes extref:{contributors}[committers, staff-committers] footnote:[extref:{contributors}[committers, staff-committers]] são normalmente as pessoas que fazem a maior parte do desenvolvimento do FreeBSD. Um https://www.FreeBSD.org/administration/#t-core[Core team]footnote:[https://www.FreeBSD.org/administration/#t-core[Core Team do FreeBSD]] eleito fornece algum nível de orientação sobre o projeto.

O ritmo acelerado de desenvolvimento do `FreeBSD` torna a principal branch de desenvolvimento inadequada para o uso diário pelo público em geral. Em particular, são necessários esforços de estabilização 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 várias trilhas paralelas. A principal branch de desenvolvimento é a _HEAD_ ou _trunk_ da nossa árvore do Subversion, conhecida como "FreeBSD-CURRENT" ou "-CURRENT" quando abreviado.

Um conjunto de branches mais estáveis é mantido, e é conhecido como "FreeBSD-STABLE" ou "-STABLE" na forma abreviada. Todas as branchs ficam em um repositório principal do Subversion mantido pelo Projeto FreeBSD. O FreeBSD-CURRENT é a "vanguarda do desenvolvimento tecnológico" do FreeBSD, pelo qual todas as novas alterações entram no sistema pela primeira vez. O FreeBSD-STABLE é a branch de desenvolvimento a partir do qual as releases principais são feitas. Mudanças entram nesta branch em um ritmo diferente, e com a suposição geral de que elas foram primeiro para o FreeBSD-CURRENT e foram exaustivamente testadas por nossa comunidade de usuários.

O termo _stable_ no nome da branch refere-se à estabilidade presumida da Interface Binária da Aplicação (ABI), que é prometida pelo projeto. Isso significa que um aplicativo de usuário compilado em uma versão mais antiga do sistema da mesma branch funciona em um sistema mais novo da mesma branch. A estabilidade do ABI melhorou muito em relação às versões anteriores. Na maioria dos casos, os binários dos sistemas _STABLE_ mais antigos são executados sem modificações em sistemas mais recentes, incluindo o __HEAD__, assumindo que as interfaces de gerenciamento do sistema não são usadas.

No período intermediário entre as versões, snapshots semanais são construídos automaticamente pelas máquinas de build do Projeto FreeBSD e disponibilizados para download em `ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/`. A ampla disponibilidade de snapshots binários e a tendência da nossa comunidade de usuários para acompanhar o desenvolvimento do -STABLE com o Subversion e `"make buildworld"` footnote:[extref:{handbook}updating-upgrading[Re-construindo o 'mundo', makeworld]] ajuda a manter o FreeBSD-STABLE em uma condição muito confiável, mesmo antes que as atividades de garantia de qualidade aumentem na proximidade de um grande lançamento.

Além dos snapshots de instalação no formato ISO, imagens semanais de máquinas virtuais também são fornecidas para uso com o VirtualBox, o qemu ou outros softwares populares de emulação. As imagens de máquinas virtuais podem ser baixadas em `ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/`.

As imagens das máquinas virtuais tem aproximadamente 150MB compactadas com o man:xz[1] e contêm um sistema de arquivos esparso de 10GB quando atachado a uma máquina virtual.

Relatórios de bugs e solicitações de recursos são enviados continuamente pelos usuários durante todo o ciclo da release. Os relatórios de problemas são inseridos em nosso banco de dados do Bugzilla por meio da interface da Web disponibilizada em https://www.freebsd.org/support/bugreports/[https://www.freebsd.org/support/bugreports/].

Para atender nossos usuários mais conservadores, versões individuais foram introduzidas com o FreeBSD 4.3. Estas branchs de versões são criadas pouco antes de uma liberação final ser feita. Após o lançamento, somente as correções e adições de segurança mais críticas são aplicadas na branch da versão. Além das atualizações do código fonte via Subversion, patchkits binários estão disponíveis para manter os sistemas nas branchs _releng/X.Y_ atualizadas.

=== O que Este Artigo Descreve

As seções a seguir deste artigo descrevem:

<<release-proc>>::
As diferentes fases do processo de engenharia de release que levam à criação do sistema atual.

<<release-build>>::
O processo de criação atual.

<<extensibility>>::
Como o release base pode ser estendido por terceiros.

<<lessons-learned>>::
Algumas das lições aprendidas através do lançamento do FreeBSD 4.4.

<<future>>::
Direções futuras de desenvolvimento.

[[release-proc]]
== Processos de Release (Versão)

Novas versões do FreeBSD são liberadas a partir da branch -STABLE em intervalos de aproximadamente quatro meses. O processo de release do FreeBSD começa a se desenhar cerca de 70-80 dias antes da data de lançamento prevista, quando o engenheiro de versão envia um email para as listas de discussão de desenvolvimento para lembrar aos desenvolvedores que eles só têm 15 dias para integrar novas alterações antes do congelamento de código. Durante esse tempo, muitos desenvolvedores executam o que ficou conhecido como "MFC sweeps".

MFC significa "Merge From CURRENT" e descreve o processo de fusão de uma alteração testada de nossa branch de desenvolvimento -CURRENT com a nossa branch -STABLE. A política do projeto requer que qualquer mudança seja aplicada pela primeira vez ao trunk, e aplicada às branches -STABLE após testes externos suficientes serem feitos pelos usuários no -CURRENT (espera-se que os desenvolvedores testem extensivamente a mudança antes de enviarem a mesma para o -CURRENT, mas é impossível para uma pessoa exercer todos os usos de um sistema operacional de propósito geral). O período mínimo de MFC é de 3 dias, que normalmente é usado apenas para correções de bugs triviais ou críticas.

=== Revisão de código

Sessenta dias antes do lançamento previsto, o repositório de código entra um "congelamento de código". Durante esse tempo, todos os commits para a branch -STABLE devem ser aprovados pela equipe de engenharia de release (versão) mailto:re@FreeBSD.org[re@FreeBSD.org]. O processo de aprovação é tecnicamente aplicado por um "pre-commit hook". Os tipos de alterações permitidos durante esse período incluem:

* Correções de bugs.
* Atualizações de documentação.
* Correções relacionadas à segurança de qualquer tipo.
* Pequenas alterações nos drivers de dispositivos, como a adição de novos IDs de dispositivos.
* Atualizações de driver dos fornecedores.
* Qualquer mudança adicional que a equipe de engenharia de release julgue justificada, dado o risco potencial.

Logo após o início do congelamento de código, uma imagem _BETA1_ é criada e liberada para testes generalizados. Durante o congelamento de código, pelo menos uma imagem beta ou um candidato a versão é lançado a cada duas semanas até que a versão final esteja pronta. Durante os dias que antecedem a versão final, a equipe de engenharia de release está em constante comunicação com a equipe de segurança, os mantenedores de documentação e os mantenedores de ports para garantir que todos os diferentes componentes necessários para uma versão bem-sucedida estejam disponíveis.

Após a qualidade das imagens BETA ser satisfatória o suficiente, e nenhuma mudança grande e potencialmente arriscada estar planejada, a branch release é criada e as imagens _Release Candidate_ (RC) são construídas a partir da branch release, ao invés das Imagens BETA serem construidas da branch STABLE. Além disso, o congelamento na branch STABLE é suspenso e a branch de release entra em um "congelamento de código rígido", onde fica muito mais difícil justificar novas alterações no sistema, a menos que envolva uma correção séria de bug ou um problema de segurança.

=== Checklist Final para uma Release

Quando várias imagens BETA já tiverem sido disponibilizadas para testes generalizados e todos os principais problemas tiverem sido resolvidos, o "polimento" da versão final pode começar.

[[rel-branch]]
==== Criação da Branch (Ramificação) da Release (Versão)

[NOTE]
====
Em todos os exemplos abaixo, `$FSVN` refere-se ao local do repositório Subversion do FreeBSD, `svn+ssh://svn.FreeBSD.org/base/`.
====

O layout das branchs do FreeBSD no Subversion é descrito no extref:{committers-guide}[Guia do Commiter, subversion-primer-base-layout]. O primeiro passo na criação de uma branch é identificar a revisão do código fonte do `stable/_X_`, a partir do qual você deseja criar a nova _branch_.

[source,shell]
....
# svn log -v $FSVN/stable/9
....

O próximo passo é criar a _branch da release_

[source,shell]
....
# svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2
....

Esta branch pode ser obtida com:

[source,shell]
....
# svn co $FSVN/releng/9.2 src
....

[NOTE]
====
A criação das tags da branch `releng` e de `release` é feita pela https://www.FreeBSD.org/administration/#t-re[Equipe de Engenharia de Release].
====

image::branches-head.png[Branch de Desenvolvimento do FreeBSD]

image::branches-releng3.png[Branch FreeBSD 3.x STABLE]

image::branches-releng4.png[Branch FreeBSD 4.x STABLE]

image::branches-releng5.png[Branch FreeBSD 5.x STABLE]

image::branches-releng6.png[Branch FreeBSD 6.x STABLE]

image::branches-releng7.png[Branch FreeBSD 7.x STABLE]

image::branches-releng8.png[Branch FreeBSD 8.x STABLE]

image::branches-releng9.png[Branch FreeBSD 9.x STABLE]

[[versionbump]]
==== Incrementando o número da versão

Antes que a versão final possa ser marcada, construída e lançada, os seguintes arquivos precisam ser modificados para refletir a versão correta do FreeBSD:

* [.filename]#doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml#
* [.filename]#doc/en_US.ISO8859-1/books/porters-handbook/book.xml#
* [.filename]#doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi#
* [.filename]#ports/Tools/scripts/release/config#
* [.filename]#doc/shared/xml/freebsd.ent#
* [.filename]#src/Makefile.inc1#
* [.filename]#src/UPDATING#
* [.filename]#src/gnu/usr.bin/groff/tmac/mdoc.local#
* [.filename]#src/release/Makefile#
* [.filename]#src/release/doc/en_US.ISO8859-1/shared/xml/release.dsl#
* [.filename]#src/release/doc/shared/examples/Makefile.relnotesng#
* [.filename]#src/release/doc/shared/xml/release.ent#
* [.filename]#src/sys/conf/newvers.sh#
* [.filename]#src/sys/sys/param.h#
* [.filename]#src/usr.sbin/pkg_install/add/main.c#
* [.filename]#doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml#

As notas de versão e os arquivos de errata também precisam ser ajustados para a nova versão (na branch (ramificação) da release) e truncados apropriadamente (na branch stable/current):

* [.filename]#src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml#
* [.filename]#src/release/doc/en_US.ISO8859-1/errata/article.xml#

O Sysinstall deve ser atualizado para exibir o número de ports disponíveis e a quantidade de espaço em disco necessária para a Coleção de Ports. footnote:[Coleção de Ports do FreeBSD https://www.FreeBSD.org/ports] Esta informação é atualmente mantida em [.filename]#src/usr.sbin/bsdinstall/dist.c#.

Após a release ter sido construida, vários arquivos devem ser atualizados para anunciar a versão para o mundo. Esses arquivos são relativos a `head/` dentro da árvore `doc/` do subversion.

* [.filename]#share/images/articles/releng/branches-relengX.pic#
* [.filename]#head/shared/xml/release.ent#
* [.filename]#en_US.ISO8859-1/htdocs/releases/*#
* [.filename]#en_US.ISO8859-1/htdocs/releng/index.xml#
* [.filename]#share/xml/news.xml#

Além disso, atualize o arquivo da "Árvore Genealógica do BSD":

* [.filename]#src/shared/misc/bsd-family-tree#

==== Criando a Tag de Release

Quando a versão final estiver pronta, o seguinte comando criará a tag `release/9.2.0`.

[source,shell]
....
# svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0
....

Os gerentes de Documentação e do Ports são responsáveis por marcar suas respectivas árvores com a tag `tags/RELEASE_9_2_0`.

Quando o comando `svn cp` do Subversion é usado para criar uma __tag de versão__, isso identifica o código fonte em um ponto específico no tempo. Criando tags, nós garantimos que futuros construtores de versões sempre poderão usar exatamente o mesmo código fonte que usamos para criar as releases oficiais do Projeto FreeBSD.

[[release-build]]
== Construção da Release (Versão)

As "releases" do FreeBSD podem ser construídas por qualquer pessoa com uma máquina rápida e acesso a um repositório de código-fonte. (Isso deveria ser todo mundo, já que oferecemos acesso ao Subversion! Veja a seção sobre extref:{handbook}mirrors[Subversion, svn] no Handbook para detalhes.) O _único_ requisito especial é que o dispositivo man:md[4] esteja disponível. Se o dispositivo não estiver carregado em seu kernel, então o módulo do kernel deve ser carregado automaticamente quando o man:mdconfig[8] for executado durante a fase de criação da mídia de boot. Todas as ferramentas necessárias para construir uma release estão disponíveis no repositório Subversion em [.filename]#src/release#. Essas ferramentas visam fornecer uma maneira consistente de construir versões do FreeBSD. Uma release completa pode ser construída com apenas um único comando, incluindo a criação de imagens ISO adequadas para gravação em CD-ROM ou DVD e um diretório para instalação por FTP. A pagina de manual  man:release[7] documenta completamente o script `src/release/generate-release.sh` que é usado para construir uma release. O `generate-release.sh` é um invólucro em torno do target do Makefile: `make release`.

=== Construindo uma Release (Versão)

A página de manual man:release[7] documenta os comandos exatos necessários para construir uma Release do FreeBSD. As seguintes sequências de comandos podem construir uma versão 9.2.0:

[source,shell]
....
# cd /usr/src/release
# sh generate-release.sh release/9.2.0 /local3/release
....

Depois de executar esses comandos, todos os arquivos preparados da versão estarão disponíveis no diretório [.filename]#/local3/release/R#.

O release [.filename]#Makefile# pode ser dividido em várias etapas distintas.

* Criação de um ambiente de sistema limpo em uma hierarquia de diretório separada com "`make installworld`".
* Checkout do Subversion de uma versão limpa do código fonte do sistema, da documentação e e da coleção de ports na hierarquia de build do release.
* Popula o [.filename]#/etc# e o [.filename]#/dev# no ambiente chrooted (Processo de transferir o diretório root para outro lugar).
* Faz chroot na hierarquia de build (construção) da release, para tornar mais difícil para o ambiente externo corromper essa construção.
* Execução do comando `make world` no ambiente chrooted.
* Compilação dos binários relacionados ao Kerberos.
* Compilação do kernel [.filename]#GENERIC#.
* Criação uma árvore de diretórios temporários onde as distribuições binárias serão compiladas e empacotadas.
* Compilação e instalação do toolchain necessário para converter o fonte da documentação (SGML) em HTML e demais documentos de texto que acompanharão a versão.
* Compilação e instalação da documentação propriamente dita (manuais do usuário, tutoriais, notas de versão, listas de compatibilidade de hardware e assim por diante).
* Empacotamento dos tarballs de distribuição dos binários e fontes.
* Criação da hierarquia de instalação por FTP.
* _(opcionalmente)_ Criação das imagens ISO para mídia de CDROM/DVD.

Para obter maiores informações sobre a infraestrutura de criação de versões, consulte man:release[7].

[NOTE]
====
É importante remover qualquer configuração específica do seu servidor do [.filename]#/etc/make.conf#. Por exemplo, seria imprudente distribuir binários que foram compilados em um sistema com `CPUTYPE` configurado para um processador específico.
====

=== Software Contribuído ("ports")

A https://www.FreeBSD.org/ports[Coleção de Ports do FreeBSD] é uma coleção de mais de 24.000 pacotes de software de terceiros disponíveis para o FreeBSD. A Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org] é responsável por manter uma árvore de ports consistente que pode ser usada para criar os pacotes binários que acompanham as releases oficiais do FreeBSD.

=== ISOs das Releases (Versões)

Começando no FreeBSD 4.4, o Projeto FreeBSD decidiu liberar todas as quatro imagens ISO que eram vendidas anteriormente nas distribuições "oficiais" em CDROM pela __BSRi/Wind River Systems/FreeBSD Mall__. Cada um dos quatro discos deve conter um arquivo [.filename]#README.TXT# que explica o conteúdo do disco, um arquivo [.filename]#CDROM.INF# que fornece metadados do disco para que o man:bsdinstall[8] possa validar e usar o conteúdo, e um arquivo [.filename]#filename.txt# que fornece um manifesto para o disco. Este _manifesto_ pode ser criado com um simples comando:

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

Os requisitos específicos de cada CD são descritos abaixo.

==== Disco 1

O primeiro disco é quase completamente criado por `make release`. As únicas alterações que devem ser feitas no diretório [.filename]#disc1# são a adição de um diretório [.filename]#tools# e tantos pacotes de software de terceiros quanto couberem no disco. O diretório [.filename]#tools# contém software que permite aos usuários criar disquetes de instalação a partir de outros sistemas operacionais. Esse disco deve ser inicializado para que os usuários dos PCs modernos não precisem criar disquetes de instalação.

Se um kernel customizado do FreeBSD precisa ser incluído, então o man:bsdinstall[8] e o man:release[7] deve ser atualizado para incluir instruções de instalação. O código relevante está contido em [.filename]#src/release# e [.filename]#src/usr.sbin/bsdinstall#. Especificamente, os arquivos [.filename]#src/release/Makefile#, [.filename]#dist.c#, [.filename]#dist.h#, [.filename]#menus.c# , [.filename]#install.c#, e [.filename]#Makefile# precisarão ser atualizados em [.filename]#src/usr.sbin/bsdinstall#. Opcionalmente, você pode escolher atualizar o [.filename]#bsdinstall.8#.

==== Disco 2

O segundo disco também é largamente criado por `make release`. Este disco contém um "live filesystem" que pode ser usado por man:bsdinstall[8] para solucionar problemas de instalação do FreeBSD. Este disco deve ser inicializável e também deve conter uma cópia compactada do repositório CVS no diretório [.filename]#CVSROOT# e demos de software comercial no diretório [.filename]#commerce#.

==== Suporte para vários volumes

O Sysinstall suporta a instalação de pacotes a partir de vários volumes. Isso requer que cada disco tenha um arquivo [.filename]#INDEX# contendo todos os pacotes em todos os volumes de um conjunto, junto com um campo extra que indica em qual volume esse pacote específico está. Cada volume no conjunto também deve ter a variável `CD_VOLUME` definida no arquivo [.filename]#cdrom.inf# para que o bsdinstall possa informar qual volume é qual. Quando um usuário tentar instalar um pacote que não esteja no disco atual, o bsdinstall solicitará que o usuário insira o disco apropriado.

[[distribution]]
== Distribuição

[[dist-ftp]]
=== Sites FTP

Quando a release for totalmente testada e empacotada para distribuição, o site FTP principal deverá ser atualizado. Os sites de FTP públicos oficiais do FreeBSD são todos espelhos de um servidor principal que está acessível somente a outros sites FTP. Este site é conhecido como `ftp-master`. Quando a release estiver pronta, os seguintes arquivos devem ser modificados no `ftp-master`:

[.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/#::
O diretório FTP instalável como saída de `make release`.

[.filename]#/pub/FreeBSD/ports/arch/packages-X.Y-release/#::
O pacote completo criado para esta versão.

[.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools#::
Um link simbólico para [.filename]#../../../tools#.

[.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/packages#::
Um link simbólico para [.filename]#../../../ports/arch/packages-X.Y-release#.

[.filename]#/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso#::
As imagens ISO. O "*" é o [.filename]#disc1#, [.filename]#disc2#, etc. Somente se houver um [.filename]#disc1# e houver um CD alternativo para o primeiro disco de instalação (por exemplo, uma instalação simplificada sem sistema de janelas) também pode haver um [.filename]#mini#.

Para mais informações sobre a arquitetura do sistema de espelhamento dos sites de FTP para distribuição do FreeBSD, por favor veja o artigo extref:{hubs}[Espelhando o FreeBSD].

Pode levar de muitas horas a dois dias após a atualização 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 não carregado ao mesmo tempo. É imperativo que os engenheiros de release coordenem com os http://lists.FreeBSD.org/mailman/listinfo/mirror-announce[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 lançamento. Os bits da release devem ser carregados entre 24 e 48 horas antes do horário de lançamento planejado com as permissões de arquivo "other" desativadas. Isso permitirá que os sites espelho façam o download, mas o público em geral não poderá baixá-los dos sites espelho. Um e-mail deve ser enviado para a lista dos http://lists.FreeBSD.org/mailman/listinfo/mirror-announce[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 horário em que os sites espelho devem começar a permitir o acesso. Certifique-se de incluir um fuso horário com a hora, por exemplo, torná-lo relativo ao GMT.

[[dist-cdrom]]
=== Replicação do CD-ROM

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

[[extensibility]]
== Extensibilidade

Embora o FreeBSD forme um sistema operacional completo, não há nada que force você a usar o sistema exatamente como o empacotamos para distribuição. Tentamos projetar o sistema para ser o mais extensível possível, de modo que ele possa servir como uma plataforma na qual outros produtos comerciais possam ser construídos. A única "regra" que temos sobre isso é que se você for distribuir o FreeBSD com mudanças não triviais, nós encorajamos você a documentar suas melhorias! A comunidade do FreeBSD só pode ajudar a suportar usuários do software que fornecemos. Nós certamente encorajamos a inovação na forma de ferramentas avançadas de instalação e administração, por exemplo, mas você não esperar que respondamos perguntas sobre isso.

=== Usando o script `bsdinstall`

A ferramenta de instalação e configuração do sistema FreeBSD, man:bsdinstall[8], pode ser programada para fornecer instalações automatizadas para sites grandes. Essa funcionalidade pode ser usada em conjunto com Intel(R) PXE footnote:[extref:{handbook}advanced-networking[Network PXE NFS, network-pxe-nfs]] para inicializar sistemas da rede.

[[lessons-learned]]
== Lições Aprendidas do FreeBSD 4.4

O processo de engenharia de release do 4.4 começou formalmente em 1º de agosto de 2001. Após essa data, todos os commits da branch `RELENG_4` do FreeBSD tiveram que ser explicitamente aprovados pela Equipe de Engenharia de Release mailto:re@FreeBSD.org[re@FreeBSD.org]. O primeiro release candidate para a arquitetura x86 foi lançado em 16 de agosto, seguido por mais 4 candidatos a versão que antecederam a versão final em 18 de setembro. O agente de segurança esteve muito envolvido na última semana do processo, pois vários problemas de segurança foram encontrados nos candidatos anteriores. Um total de mais de _500_ e-mails foram enviados para a Equipe de Engenharia de Release mailto:re@FreeBSD.org[re@FreeBSD.org] em pouco mais de um mês.

Nossa comunidade de usuários deixou bem claro que a segurança e a estabilidade de uma versão do FreeBSD não devem ser sacrificadas por quaisquer prazos auto-impostos ou datas-alvo de lançamento. O projeto FreeBSD cresceu tremendamente ao longo de sua existência e a necessidade de procedimentos padronizados de engenharia de versões nunca foi tão aparente. Isso se tornará ainda mais importante à medida que o FreeBSD for portado para novas plataformas.

[[future]]
== Direções futuras

É imperativo que nossas atividades de engenharia de release sejam escaladas com nossa crescente base de usuários. Nessa linha, estamos trabalhando muito para documentar os procedimentos envolvidos na produção de versões do FreeBSD.

* _Paralelismo_ - Algumas partes da compilação da release são, na verdade, "embaraçosamente paralelas". A maioria das tarefas é muito intensiva em I/O, portanto, ter várias unidades de disco de alta velocidade é realmente mais importante do que usar vários processadores para acelerar o processo do `make release`. Se vários discos forem usados para hierarquias diferentes no ambiente man:chroot[2], o CVS checkout das árvores do [.filename]#ports# e do [.filename]#doc# podem estar acontecendo simultaneamente como o `make world` em outro disco. Usar uma solução `RAID` (hardware ou software) pode diminuir significativamente o tempo de compilação geral.
* _Releases cross-building_ - Criação do release IA-64 ou Alpha em hardware x86? Use o comando `make TARGET=ia64 release`.
* _Teste de regressão_ - Precisamos de melhores testes automatizados para o FreeBSD.
* _Ferramentas de instalação_ - Nosso programa de instalação há muito tempo ultrapassou à sua expectativa de vida útil. Vários projetos estão em desenvolvimento para fornecer um mecanismo de instalação mais avançado. O projeto libh era um desses projetos que visava fornecer um novo e inteligente framework de pacotes e um programa de instalação GUI.

[[ackno]]
== 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 também por todo o seu trabalho ao longo dos anos fazendo do FreeBSD o que é hoje. É claro quea Release não teria sido possível sem todo o trabalho relacionado a release feito por Satoshi Asami mailto:asami@FreeBSD.org[asami@FreeBSD.org], Steve Price mailto:steve@FreeBSD.org[steve@FreeBSD.org], Bruce A. Mah mailto:bmah@FreeBSD.org[bmah@FreeBSD.org], Nik Clayton mailto:nik@FreeBSD.org[nik@FreeBSD.org], David O'Brien mailto:obrien@FreeBSD.org[obrien@FreeBSD.org], Kris Kennaway mailto:kris@FreeBSD.org[kris@FreeBSD.org], John Baldwin mailto:jhb@FreeBSD.org[jhb@FreeBSD.org] e o resto da comunidade de desenvolvimento do FreeBSD. Eu também gostaria de agradecer a Rodney Grimes mailto:rgrimes@FreeBSD.org[rgrimes@FreeBSD.org], Poul-Henning Kamp mailto:phk@FreeBSD.org[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 footnote:[Marshall Kirk McKusick, Michael J. Karels e Keith Bostic: A Engenharia de Release do 4.3BSD], o Projeto NetBSD, footnote:[Documentação do desenvolvedor do NetBSD: Engenharia de Release http://www.NetBSD.org/developers/releng/index.html], e as notas de processo de engenharia de release propostas por John Baldwin. footnote:[Proposta de engenharia de Release do FreeBSD de John Baldwin https://people.FreeBSD.org/~jhb/docs/releng.txt]
