Engenharia de Release do FreeBSD

Murray Stokely

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

Nota Legal

2018-09-21 03:22:51 por ebrandi.

Resumo

Nota:

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 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.

[ Documento HTML em partes / Documento HTML completo ]

1. 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 [1] 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 committers [2] são normalmente as pessoas que fazem a maior parte do desenvolvimento do FreeBSD. Um Core team [3] 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” [4] 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 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.html.

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.

1.1. O que Este Artigo Descreve

As seções a seguir deste artigo descrevem:

Seção 2, “Processos de Release (Versão) ”

As diferentes fases do processo de engenharia de release que levam à criação do sistema atual.

Seção 3, “Construção da Release (Versão)”

O processo de criação atual.

Seção 5, “Extensibilidade”

Como o release base pode ser estendido por terceiros.

Seção 6, “Lições Aprendidas do FreeBSD 4.4”

Algumas das lições aprendidas através do lançamento do FreeBSD 4.4.

Seção 7, “Direções futuras”

Direções futuras de desenvolvimento.

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

[2] Committers do FreeBSD

[3] Core Team do FreeBSD

[4] Re-construindo o "mundo"

2. 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.

2.1. 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) <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.

2.2. 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.

2.2.1. Criação da Branch (Ramificação) da Release (Versão)

Nota:

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 Guia do Commiter. 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.

# svn log -v $FSVN/stable/9

O próximo passo é 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 criação das tags da branch releng e de release é feita pela Equipe de Engenharia de Release.

2.2.2. 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:

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 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):

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 número de ports disponíveis e a quantidade de espaço em disco necessária para a Coleção de Ports. [5] Esta informação é atualmente mantida em 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.

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

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

src/share/misc/bsd-family-tree

2.2.3. Criando a Tag de Release

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

# 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.

[5] Coleção de Ports do FreeBSD https://www.FreeBSD.org/port

3. 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 Subversion no Handbook para detalhes.) O único requisito especial é que o dispositivo 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 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 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 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.

3.1. Construindo uma Release (Versão)

A página de manual 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:

# 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 /local3/release/R.

O release 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 /etc e o /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 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 release(7).

Nota:

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

3.2. Software Contribuído (“ports”)

A 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 <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.

3.3. 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 README.TXT que explica o conteúdo do disco, um arquivo CDROM.INF que fornece metadados do disco para que o bsdinstall(8) possa validar e usar o conteúdo, 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 específicos de cada CD são descritos abaixo.

3.3.1. Disco 1

O primeiro disco é quase completamente criado por make release. As únicas alterações que devem ser feitas no diretório disc1 são a adição de um diretório tools e tantos pacotes de software de terceiros quanto couberem no disco. O diretório 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 bsdinstall(8) e o release(7) deve ser atualizado para incluir instruções de instalação. O código relevante está 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 precisarão ser atualizados em src/usr.sbin/bsdinstall. Opcionalmente, você pode escolher atualizar o bsdinstall.8.

3.3.2. Disco 2

O segundo disco também é largamente criado por make release. Este disco contém um “live filesystem” que pode ser usado por 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 CVSROOT e demos de software comercial no diretório commerce.

3.3.3. 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 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 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.

4. Distribuição

4.1. 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:

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

O diretório FTP instalável como saída de make release.

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

O pacote completo criado para esta versão.

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

Um link simbólico para ../../../tools.

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

Um link simbólico para ../../../ports/arch/packages-X.Y-release.

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

As imagens ISO. O “*” é o disc1, disc2 , etc. Somente se houver um 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 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 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 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 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.

4.2. 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.

5. 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.

5.1. Usando o script bsdinstall

A ferramenta de instalação e configuração do sistema FreeBSD, bsdinstall(8), pode ser programada para fornecer instalações automatizadas para sites grandes. Essa funcionalidade pode ser usada em conjunto com Intel® PXE [6] para inicializar sistemas da rede.

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

6. 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 <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 <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.

7. 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 chroot(2), o CVS checkout das árvores do ports e do 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.

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 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 <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 também 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]

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

[8] Documentação 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