Engenharia de Release do FreeBSD

Embora o code slush não seja um congelamento mandatório da árvore, a Equipe de Engenharia de Release do FreeBSD solicita que resoluções dos bugs existentes no código tenham prioridade sobre implementação de novos recursos.

O code slush não impõe aprovações de confirmação para o Branch.

O code freeze marca o momento em que todos os commits para a branch exigem aprovação explícita da Equipe de Engenharia de Release do FreeBSD.

O repositório Subversion do FreeBSD contém vários ganchos para executar verificações de integridade antes que qualquer commit seja realmente confirmado na árvore. Um desses ganchos avaliará se o comprometimento com uma branch específica requer aprovação específica.

Para impor aprovações de commit pela Equipe de Engenharia de Release do FreeBSD, o Engenheiro de Release atualiza o base/svnadmin/conf/approvers, e aplica a mudança de volta para o repositório. Feito isso, qualquer alteração na branch deve incluir uma linha "Aprovado por:" na mensagem de commit.

A linha "Aprovada por:" deve corresponder à segunda coluna em base/svnadmin/conf/aprovovers, caso contrário, o commit será rejeitado pelos hooks do repositório.

A estabilidade de KBI/KPI implica que o caller (que faz uma chamada) de uma função através de duas versões diferentes de software que implementam a função, resulta no mesmo estado final. O caller, seja um processo, thread ou função, espera que a função opere de uma determinada maneira, caso contrário, a estabilidade do KBI/KPI na branch é interrompida.

Quando o cronograma do ciclo de release está disponível, esses arquivos precisam ser atualizados para habilitar várias funcionalidades diferentes no site do Projeto FreeBSD:

Ao fazer a transição de PRERELEASE para BETA, esses arquivos precisam ser atualizados para ativar o bloco "Teste de ajuda" na página de download. Todos os arquivos são relativos ao head/ no repositório doc:

Uma vez criada a branch releng/12.0/, os diversos documentos relacionados à release precisam ser gerados e adicionados manualmente ao repositório doc/.

Dentro de release/doc, invoque make(1) para gerar as páginas errata.html, hardware.html, readme.html e relnotes.html, que são então adicionadas ao diretório doc/head/en_US.ISO8859-1/htdocs/releases/XYR/, em que XY representa o número da versão principal e da versão secundária.

A propriedade fbsd:nokeywords deve ser definido como on nos arquivos recém-adicionados para que os hooks de pré-commit permitam que eles sejam adicionados ao repositório.

Para cada compilação durante o ciclo de release, os arquivos MANIFEST contendo o SHA256 dos vários conjuntos de distribuição, como base.txz, kernel.txz, e assim por diante, são adicionados ao port misc/freebsd-release-manifests. Isso permite outros utilitários além do bsdinstall(8), como ports-mgmt/poudriere, usem esses conjuntos de distribuição com segurança fornecendo um mecanismo através do qual os checksums possam ser verificados.

Tendo aparecido primeiramente durante o ciclo de release do FreeBSD 10.0-RELEASE, a noção de compilações de fases “ALPHA” foi introduzida. Ao contrário das compilações BETA e RC, as compilações desse novo estágio ALPHA não fazem parte do cronograma de Release do FreeBSD.

A idéia por trás das compilações ALPHA é disponibilizar builds regulares fornecidas pelo FreeBSD antes da criação da branch stable/.

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

Para a primeira compilação ALPHA, o valor BRANCH em sys/conf/newvers.sh precisa ser alterado de CURRENT para ALPHA1. Para compilações ALPHA subsequentes, incremente cada valor de ALPHAN em um.

Veja Construindo a Mídia de Instalação do FreeBSD para informações sobre como construir as imagens ALPHA.

Ao criar a branch stable/, várias alterações são necessárias na nova branch stable/ e na branch head/. Os arquivos listados são relativos ao repositório raiz. Para criar a nova branch stable/12/ no Subversion:

Uma vez que a branch stable/12/ tenha sido criada, faça as seguintes edições:

Então, na branch head/, que agora se tornará uma nova versão principal:

Na preparação para o code freeze em uma branch stable, vários arquivos precisam ser atualizados para refletir o ciclo de release que está oficialmente em andamento. Esses arquivos são todos relativos ao nível mais alto da branch stable:

No repositório doc, atualize também head/pt_BR.ISO8859-1/htdocs/releases/12.0R/Makefile.hardware, alternando o valor de _BRANCH para BETAX, RCX ou RELEASE, respectivamente.

Após o code slush, a próxima fase do ciclo de release é o code freeze. Este é o ponto no qual todos os commits para a branch stable requerem aprovação explícita da Equipe de Engenharia de Release do FreeBSD. Isto é reforçado por hooks de pré-commit no repositório Subversion editando base/svnadmin/conf/approvers para incluir uma expressão regular que coincida com a branch stable/12/ para a release:

Quando o code freeze estiver em vigor, a próxima construção da branch será rotulada como BETA1. Isso é feito atualizando o valor de BRANCH em sys/conf/newvers.sh de PRERELEASE para BETA1.

Feito isso, o primeiro conjunto de builds BETA é iniciado. Builds BETA subseqüentes não requerem atualizações em nenhum arquivo diferente do sys/conf/newvers.sh, incrementando o número de compilação da versão BETA.

Quando a primeira construção RC (Release Candidate) está pronta para começar, a branch releng/ é criada. Este é um processo de várias etapas que deve ser feito em uma ordem específica, a fim de evitar anomalias, como sobreposições com valores de __FreeBSD_version, por exemplo. Os caminhos listados abaixo são relativos ao repositório raiz. A ordem dos commits e o que mudar são:

Agora que existem dois novos valores de __FreeBSD_version, também atualize head/pt_BR.ISO8859-1/books/porters-handbook/versions/chapter.xml no repositório do Projeto de Documentação.

Depois que a primeira compilação de um RC estiver concluída e testada, a branch stable/ pode ser "descongelada" removendo (ou comentando) a entrada ^/stable/12/ em svnadmin/conf/approvers.

Seguindo a disponibilidade do primeiro RC, o Time Bugmeister do FreeBSD deve ser avisado por e-mail para adicionar o novo FreeBSD -RELEASE às versões disponíveis no menu drop-down exibido no rastreador de bugs.

Esta seção descreve os scripts de build usados pela Equipe de Engenharia de Release do FreeBSD para produzir snapshots da versão em desenvolvimento e das releases.

As máquinas oficiais de compilação de versões têm um layout do sistema de arquivos específico, que utiliza ZFS, o thermite.sh tira grande proveito de clones e snapshots, garantindo um ambiente de compilação uniforme e consistente.

Os scripts de compilação localizam-se respectivamente em /releng/scripts-snapshot/scripts ou /releng/scripts-release/scripts, para evitar colisões entre uma compilação RC de uma branch releng contra um snapshot STABLE da respectiva branch stable.

Existe um dataset (conjunto de dados) separado para as imagens finais de compilação, /snap/ftp. Este diretório contém diretórios de snapshots e releases. Eles são usados apenas se a variável EVERYTHINGISFINE estiver definida em main.conf.

Como o thermite.sh percorre a lista principal de combinações e localiza o arquivo de configuração por compilação, um dataset ZFS é criado sob o /releng, tal como /releng/12-amd64-GENERIC-snap. O checkout das árvores src/, ports/ e doc/ é realizado em diferentes datasets ZFS, tal como /releng/12-src-snap, os quais são então clonados e montados nos respectivos datasets de compilação. Isso é feito para evitar a remoção de uma determinada árvore mais de uma vez.

Assumindo esses caminhos do sistema de arquivos, o thermite.sh deveria ser chamado como:

Quando as compilações forem concluídas, scripts adicionais auxiliares estarão disponíveis para gerar e-mails de snapshots de desenvolvimento que são enviados para a lista de e-mail freebsd-snapshots@freebsd.org:

Similar a compilação de snapshots de desenvolvimento do FreeBSD, o thermite.sh seria invocado da mesma maneira. A diferença entre snapshots de desenvolvimento e builds de releases, BETA e RC inclusos, é que os arquivos de configuração do chroot(8) devem ser nomeados com release ao invés de snap no "type", como mencionado acima.

Além disso, BUILDTYPE e types devem ser alterados de snap para release em defaults-12.conf e builds-12.conf, respectivamente.

Ao construir o BETA, o RC, e o RELEASE final, também ajuste estaticamente o BUILDSVNREV para a revisão na branch refletindo a mudança de nome, BUILDDATE para a data em que as compilações são iniciadas no formato YYYYMMDD. Se as árvores doc/ e ports/ tiverem sido marcadas, defina também o PORTBRANCH e o DOCBRANCH para o caminho da tag relevante no repositório Subversion, substituindo HEAD pela última revisão alterada. Também defina releasesrc em builds-12.conf para a branch relevante, como stable/12/ ou releng/12.0/.

Durante o ciclo de release, uma cópia do CHECKSUM.SHA512 e do CHECKSUM.SHA256 para cada arquitetura é armazenada no repositório interno da Equipe de Engenharia de Release do FreeBSD, além de ser incluída nos diversos e-mails de anúncio. Cada MANIFEST contendo os hashes do base.txz, do kernel.txz, etc. também são adicionados ao misc/freebsd-release-manifests na coleção de ports.

Depois de construir a RELEASE final, a branch releng/12.0/ é marcada como release/12.0.0/ usando a revisão a partir da qual a RELEASE foi construída. Semelhante a criar as branches stable/12/ e releng/12.0/, isso é feito com svn cp. Da raiz do repositório:

A preparação dos snapshots e das versões do FreeBSD é um processo de duas partes:

Uma vez que as imagens são colocadas em /archive/tmp/, elas estão prontas para serem publicadas colocando-as em /archive/pub/FreeBSD. Para reduzir o tempo de propagação, o pax(1) é usado para criar links físicos a partir de /archive/tmp para /archive/pub/FreeBSD.

Há uma ressalva, no entanto, em que o rsync deve ser usado após o pax(1) para corrigir os links simbólicos no pub/FreeBSD/snapshots/ISO-IMAGES que o pax(1) irá substituir por um hard link, aumentando o tempo de propagação.

Como o usuário archive:

Substitua os snapshots por releases conforme apropriado.

A medida que o ciclo de release se aproxima da conclusão, é comum ter vários candidatos a EN (Aviso de Erratas) para abordar os problemas que foram descobertos ao final do ciclo. Após o lançamento, a Equipe de Engenharia de Release do FreeBSD e a Equipe de Segurança do FreeBSD reveem mudanças que não foram aprovadas antes da versão final, e dependendo do escopo da mudança em questão, podem emitir um EN.

Para solicitar uma Errata após a conclusão de um ciclo de lançamento, o desenvolvedor deve preencher o Template de Errata, em particular as seções Background, Problem Description, Impact e, se aplicável, as seções Workaround.

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

Para pedidos de Errata imediatamente após o lançamento, o pedido deve ser enviado por e-mail à Equipe de Engenharia de Releases do FreeBSD e à Equipe de Segurança do FreeBSD. Depois que a branch releng/ foi entregue à equipe de Segurança do FreeBSD, conforme descrito em Entrega para a Equipe de Segurança do FreeBSD, as solicitações de Errata devem ser enviadas à equipe de Segurança do FreeBSD.

Aproximadamente duas semanas após o lançamento, o Engenheiro de Release atualiza o svnadmin/conf/approvers alterando a coluna do aprovador de re para (so|security-officer) para a branch releng/12.0/.

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