Ingeniería de versiones de FreeBSD

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

Marcas registradas

FreeBSD es una marca registrada de la Fundación FreeBSD

Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, y Xeon son marcas registradas de ntel Corporation o sus subsidiarias en los Estados Unidos de América y otros países.

Muchos de los nombres usados por los fabricantes y vendedores para diferenciar sus productos son designados como marcas comerciales. Allí donde estos nombres aparezcan en este documento y el Proyecto FreeBSD fuera consciente de la alegación de marca comercial, los nombres tienen a continuación el símbolo “™” o “®”.

Tabla de contenidos

Resumen

Este artículo describe el proceso detrás del modelo de ingeniería de versiones adoptado por el Proyecto FreeBSD.

Este documento todavía no ha sido actualizado para describir los procedimientos actuales del equipo de Ingeniería de Versiones de FreeBSD que siguieron a la transición de Subversion a Git.

1. Introducción al Proceso de Ingeniería de Versiones de FreeBSD

El desarrollo de FreeBSD tiene un flujo de trabajo muy específico. En general, todos los cambios en el sistema base de FreeBSD se hacen en la rama head/, que representa la cima del árbol de fuentes.

Después de un periodo de pruebas razonable, los cambios se pueden integrar en las ramas stable/. El tiempo mínimo por defecto para integrar cambios en las ramas stable/ es de tres (3) días.

A pesar de la regla general de esperar un mínimo de tres días antes de integrar cambios desde head/, hay algunas circunstancias especiales bajo las cuales una integración inmediata puede ser necesaria, como arreglos críticos de seguridad, o un arreglo de un fallo que directamente imposibilita el proceso de generación de versiones.

Después de varios meses, y de que el número de cambios en la rama stable/ haya crecido significativamente, es hora de liberar la siguiente versión de FreeBSD. Estas versiones han sido denominadas históricamente como versiones punto ("point" releases).

Entre las versiones de las ramas stable/, aproximadamente cada dos (2) años, se sacará una versión directamente desde head/. Estas versiones se han denominado históricamente como versiones "punto cero" ("dot-zero" releases).

Este artículo resaltará el flujo de trabajo y responsabilidades del FreeBSD Release Engineering Team tanto para las versiones "dot-zero" como las versiones "point".

Las siguientes secciones de este artículo describen:

Información General y Preparación

Información general y preparación antes de comenzar el ciclo de lanzamiento.

Cambios en el Sitio Web Durante el Ciclo de Liberación

Cambios en el Sitio Web Durante el Ciclo de Liberación

Terminología de la Ingeniería de Versiones

Terminología e información general, tales como "code slush" y "code freeze", usados en este documento.

Versiones desde head/

El proceso de Ingeniería de Versiones para una versión "dot-zero".

Versiones desde stable/

El proceso de Ingeniería de Versiones para una versión "point".

Construir los Medios de Instalación de FreeBSD

Información relacionada con los procedimientos específicos para construir el medio de instalación.

Publicar los Medios de Instalación de FreeBSD para los Mirrors del Proyecto

Procedimientos para publicar un medio de instalación.

Cerrando el Ciclo de Liberación

Terminando el ciclo de lanzamiento.

2. Información General y Preparación

Aproximadamente dos meses antes del ciclo de lanzamiento, el FreeBSD Release Engineering Team decide una programación para la versión. La programación incluye varios hitos en el ciclo de lanzamiento como fechas de congelación, fechas para ramificación y fechas para construcción. Por ejemplo:

HitoFecha Esperada

head/ slush:

May 27, 2016

head/ freeze:

June 10, 2016

head/ KBI freeze:

June 24, 2016

doc/ tree slush [1]:

June 24, 2016

Rama trimestral de ports [2]:

July 1, 2016

rama stable/12/:

July 8, 2016

doc/ tree tag [3]:

July 8, 2016

Comienzo de la construcción de BETA1:

July 8, 2016

head/ thaw:

July 9, 2016

Comienzo de la construcción de BETA2:

July 15, 2016

Comienzo de la construcción de BETA3 [*]:

July 22, 2016

rama releng/12.0/:

July 29, 2016

Comienzo de la construcción de RC1:

July 29, 2016

rama stable/12/ thaw:

July 30, 2016

Comienzo de la construcción de RC2:

August 5, 2016

Construcción final de paquetes de Ports [4]:

August 6, 2016

Etiqueta de versión de Ports:

August 12, 2016

Comienzo de la construcción de RC3 [*]:

August 12, 2016

Comienzo de la construcción de RELEASE:

August 19, 2016

Anuncio de RELEASE:

September 2, 2016

Los elementos marcados con "[*]" identifican los pasos realizados solo "cuando sean necesarios".

  1. El "slush" (semi congelación) del árbol doc/ está coordinado por el FreeBSD Documentation Engineering Team.

  2. La rama trimestral de Ports que va a ser utilizada se determina por el momento en el que se planifica la construcción de la RC final. Una nueva rama trimestral es creada el primer día del trimestre, por lo que se debería usar esta métrica cuando se consideren los hitos del ciclo de lanzamiento. La rama trimestral es creada por el FreeBSD Ports Management Team.

  3. El árbol doc/ es etiquetado por el FreeBSD Documentation Engineering Team.

  4. La construcción final de los paquetes de Ports es realizada por el FreeBSD Ports Management Team después de la construcción RC definitiva (o lo que se espera que sea la definitiva).

Si la versión se está creando a partir de una rama stable/ existente, la fecha de congelación del KBI (Kernel Binary Interface) se puede excluir, ya que el KBI ya se considera congelado en ramas stable/ establecidas.

Al escribir el programa del ciclo de lanzamientos, se deben tener en cuenta varias cosas, en particular, los hitos en los que la fecha objetivo depende de los hitos predefinidos de los que exista una dependencia. Por ejemplo, la etiqueta de la Colección de Ports se obtiene de la rama trimestral que esté activa en el momento de la última fase RC. Esto, en parte, define qué rama trimestral se usa, cuándo se puede realizar la etiqueta y qué revisión del árbol de ports se usa para la compilación final de RELEASE.

Después de un acuerdo general sobre la programación, el FreeBSD Release Engineering Team envía un correo electrónico con la programación a los Desarrolladores de FreeBSD.

Es algo típico que muchos desarrolladores informen al FreeBSD Release Engineering Team sobre varios trabajos en curso. En algunos casos, se solicitará una extensión del trabajo en curso y en otros casos, se hará una petición de "blanket approval" (aprobación total) para un subconjunto particular del árbol.

Cuando se hacen tales solicitudes, es importante asegurarse de que se discutan los plazos (incluso si se estiman). Para las aprobaciones generales, el período de tiempo para la aprobación general debe quedar claro. Por ejemplo, un desarrollador de FreeBSD puede solicitar una aprobación general desde el principio del slush del código hasta el inicio de la compilación de la RC.

Para realizar el seguimiento de los "blanket approvals", el FreeBSD Release Engineering Team usa un repositorio interno para mantener un registro de esas peticiones, el cual define el área sobre la que se aprueba el "blanket approval", los autores, cuando expira la aprobación y la razón por la que fue concedido. Un ejemplo de esto es aprobar "blanket approval" para release/doc/ para todos los miembros de FreeBSD Release Engineering Team hasta la RC definitiva con el fin de actualizar las notas de la versión y otra documentación relacionada con ella.

El equipo de ingeniería de versiones de FreeBSD también utiliza este repositorio para rastrear las solicitudes de aprobación pendientes que se reciben justo antes de empezar el ciclo de compilaciones del lanzamiento, que el Ingeniero de Lanzamientos especifica el período límite con un correo electrónico a los desarrolladores de FreeBSD.

Dependiendo del conjunto de código que haya por debajo y el impacto tal que el conjunto de código tienen en FreeBSD como un todo, esas peticiones pueden ser aprobadas o denegadas por el FreeBSD Release Engineering Team.

Lo mismo se aplica al trabajo que haya en progreso. Por ejemplo, en el caso del desarrollo de un nuevo controlador, el cual está aislado del resto del árbol del código fuente, podría tener una extensión de tiempo. Sin embargo, en el caso de un nuevo planificador de procesos, puede no ser viable, en especial si los cambios no están en otra rama.

El programa también se añade a la página web del Proyecto, en el repositorio doc/, en ~/website/content/en/releases/12.0R/schedule.adoc. Este fichero se actualiza continuamente según progresa el ciclo de lanzamiento.

La mayor parte de las veces, el fichero schedule.adoc se puede copiar de una versión anterior y actualizarlo como corresponda.

Además de añadir schedule.adoc al sitio web, también se actualiza ~/shared/releases.adoc para añadir el enlace al programa a las distintas subpáginas, así como habilitar el enlace al programa en la página índice del sitio web del Proyecto.

El programa también se enlaza desde ~/website/content/en/releng/_index.adoc.

Aproximadamente un mes antes del "code slush" planificado, el FreeBSD Release Engineering Team envía un correo electrónico recordatorio a los Desarrolladores de FreeBSD.

3. Terminología de la Ingeniería de Versiones

Esta sección describe parte de la terminología utilizada en el resto de este documento.

3.1. El Code Slush

Aunque el code slush no es una congelación completa del árbol, el FreeBSD Release Engineering Team solicita que los fallos existentes en el código base tengan prioridad sobre las nuevas características.

El code slush no impone aprobaciones en los commits a la rama.

3.2. La Congelación del Código

La congelación del código marca el punto en el tiempo en el que todos los commits a la rama requieren una aprobación explícita por parte del FreeBSD Release Engineering Team.

El repositorio de Subversion de FreeBSD tiene varios hooks para realizar comprobaciones de integridad antes de que se haga cualquier commit al árbol del código fuente. Uno de esos hooks evaluará si realizar el commit a una rama en particular requiere de aprobación específica.

Para forzar la aprobación de los commits por parte del FreeBSD Release Engineering Team, el Ingeniero de Lanzamiento actualiza base/svnadmin/conf/approvers y lo escribe en el repositorio. Una vez hecho esto, cualquier cambio en la rama debe incluir una línea "Approved by:" en el mensaje de commit.

La línea "Approved by:" debe coincidir con la segunda columna del archivo base/svnadmin/conf/approvers, de lo contrario, el commit será rechazado por los hooks del repositorio.

Durante la congelación de código, se insta a los committers de FreeBSD a seguir las Change Request Guidelines.

3.3. La Congelación del KBI/KPI

La estabilidad de KBI/KPI implica que llamar a una función a través de dos versiones de software diferentes den el mismo resultado. Quien llama, ya sea un proceso, un subproceso o una función, espera que la función se comporte de cierta forma, de lo contrario, la estabilidad de KBI/KPI en la rama se ve afectada.

4. Cambios en el Sitio Web Durante el Ciclo de Liberación

Esta sección describe los cambios que deberían de ocurrir en el sitio web a medida que avanza el ciclo de lanzamiento.

Los ficheros especificados en esta sección son relativos a la rama head/ del repositorio doc en Subversion.

4.1. Cambios en el Sitio Web Antes de que Empiece el Ciclo de Lanzamiento

Cuando el programa del ciclo de lanzamientos está disponible, estos archivos deben actualizarse para habilitar varias funcionalidades diferentes en la web del Proyecto FreeBSD:

Fichero a EditarQué Cambiar

~/shared/releases.adoc

Cambia beta-upcoming de IGNORE a INCLUDE

~/shared/releases.adoc

Cambia beta-testing de IGNORE a INCLUDE

4.2. Cambios del Sitio Web Durante BETA o RC

Cuando se transita de PRERELEASE a BETA, estos ficheros necesitan ser actualizados para habilitar el bloque "Help Test" en la página de descargas. Todos los ficheros son relativos a head/ en el repositorio doc:

Fichero a EditarQué Cambiar

share/releases.adoc

Actualiza betarel-vers a BETA1

~/website/data/en/news/news.toml

Añade una entrada anunciando la BETA

~/website/static/security/advisory-template.txt

Añade la nueva BETA, RC o RELEASE final a la plantilla

~/website/static/security/errata-template.txt

Añade la nueva BETA, RC o RELEASE final a la plantilla

Una vez que se crea la rama releng/12.0/, se necesita generar los distintos documentos relativos a la versión y añadirlos manualmente al repositorio doc/.

En release/doc, invoca para generar las páginas errata.html, hardware.html, readme.html, y relnotes.html, las cuales son añadidas luego a doc/head/en_US.ISO8859-1/htdocs/releases/X.YR/, donde X.Y representan los números de versión mayor y menor del lanzamiento.

Se debe establecer la propiedad fbsd:nokeywords en los nuevos ficheros añadidos para que los hooks de pre-commit los añadan al repositorio.

Los documentos relevantes relacionados con una versión están en el repositorio doc para FreeBSD 12.x y posteriores.

4.3. Cambios en los Ports durante BETA, RC, y la RELEASE Final

Para cada construcción durante el ciclo de lanzamiento, los ficheros MANIFEST que contienen el SHA256 de los distintos conjuntos de distribuciones, como base.txz, kernel.txz y demás son añadidos al port misc/freebsd-release-manifests. Esto permite a otras utilidades, como ports-mgmt/poudriere, utilizar estos conjuntos de distribuciones de forma segura al proporcionar un mecanismo mediante el cual verificar los checksums.

5. Versiones desde head/

Esta sección describe los procedimientos generales del ciclo de lanzamiento de FreeBSD desde la rama head/.

5.1. Construcciones FreeBSD “ALPHA”

El concepto de construcción “ALPHA” se introdujo en el ciclo de FreeBSD 10.0-RELASE. A diferencia de las construcciones BETA y RC, las construcciones ALPHA no están incluidas en la programación de lanzamientos de FreeBSD.

La idea detrás de las construcciones ALPHA es proporcionar construcciones regulares de FreeBSD antes de la creación de la rama stable/.

Las instantáneas FreeBSD ALPHA se deberían construir aproximadamente una vez a la semana.

Para la primera construcción ALPHA, el valor BRANCH en sys/conf/newvers.sh tiene que cambiarse de CURRENT a ALPHA1. Para las siguientes construcciones ALPHA, incrementa cada valor ALPHAN en uno.

Visita Construir los Medios de Instalación de FreeBSD para obtener información acerca de cómo construir imágenes ALPHA.

5.2. Creando la Rama stable/12/

A la hora de crear la rama stable/ , se necesitan varios cambios tanto en la nueva rama stable/12/ como en la rama head/ . Los ficheros indicados son relativos a la raíz del repositorio. Para crear una nueva rama stable/12/ en Subversion:

% svn cp ^/head stable/12/

Una vez que la rama stable/12/ ha sido escrita en el repositorio, haz los siguientes cambios:

Fichero a EditarQué Cambiar

stable/12/UPDATING

Actualiza la versión de FreeBSD y elimina el aviso acerca de WITNESS

stable/12/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h

#ifndef MALLOC_PRODUCTION
#define MALLOC_PRODUCTION
#endif

stable/12/lib/clang/llvm.build.mk

Descomenta -DNDEBUG

stable/12/sys/*/conf/GENERIC*

Elimina el soporte para depuración

stable/12/sys/*/conf/MINIMAL

Elimina el soporte para depuración

stable/12/release/release.conf.sample

Actualiza SRCBRANCH

stable/12/sys/*/conf/GENERIC-NODEBUG

Elimina estas configuraciones del kernel

stable/12/sys/arm/conf/std.arm*

Elimina las opciones de depuración

stable/12/sys/conf/newvers.sh

Actualiza el valor de BRANCH a BETA1

stable/12/share/mk/src.opts.mk

Mueve REPRODUCIBLE_BUILD de __DEFAULT_NO_OPTIONS a __DEFAULT_YES_OPTIONS

stable/12/share/mk/src.opts.mk

Mueve LLVM_ASSERTIONS de __DEFAULT_YES_OPTIONS a __DEFAULT_NO_OPTIONS (sólo FreeBSD 13.x y posteriores)

stable/12/libexec/rc/rc.conf

Cambia dumpdev de AUTO a NO (es configurable para aquellos que lo quieren activado por defecto)

stable/12/release/Makefile

Elimina las entradas debug.witness.trace

Después, en la rama head/ , que se convertirá en una nueva versión mayor:

Fichero a EditarQué Cambiar

head/UPDATING

Actualiza la versión de FreeBSD

head/sys/conf/newvers.sh

Actualiza el valor de BRANCH para que muestre el valor CURRENT e incrementa REVISION

head/Makefile.inc1

Actualiza TARGET_TRIPLE y MACHINE_TRIPLE

head/sys/sys/param.h

Actualiza __FreeBSD_version

head/gnu/usr.bin/cc/cc_tools/freebsd-native.h

Actualiza FBSD_MAJOR y FBSD_CC_VER

head/contrib/gcc/config.gcc

Añade la sección freebsdversion.h

head/lib/clang/llvm.build.mk

Actualiza el valor de OS_VERSION

head/lib/clang/freebsd_cc_version.h

Actualiza FREEBSD_CC_VERSION

head/lib/clang/include/lld/Common/Version.inc

Actualiza LLD_REVISION_STRING

head/Makefile.libcompat

Actualiza LIB32CPUFLAGS

6. Versiones desde stable/

Esta sección describe los procedimientos generales del ciclo de lanzamiento de FreeBSD desde una rama stable/ establecida.

6.1. Code Sluch de la Rama FreeBSD stable

En preparación para la congelación del código en una rama estable, varios archivos deben ser actualizados para reflejar que el ciclo de liberación está oficialmente en curso. Estos archivos son todos relativos al nivel más alto de la rama estable:

Fichero a EditarQué Cambiar

sys/conf/newvers.sh

Actualiza el valor de BRANCH para que muestre PRERELEASE

Makefile.inc1

Actualiza TARGET_TRIPLE

lib/clang/llvm.build.mk

Actualiza OS_VERSION

Makefile.libcompat

Actualiza LIB32CPUFLAGS

6.2. Construcciones FreeBSD BETA

Después del code slush, la siguiente fase del ciclo de lanzamiento es la congelación del código. Este es el punto en el que todos los commits a la rama estable requieren de una autorización explícita del FreeBSD Release Engineering Team. Esto se fuerza mediante unos hook de pre-commit en el repositorio de Subversion, editando base/svnadmin/conf/approvers para incluir una expresión regular que concuerde con la rama stable/12/ para la versión:

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

Hay dos excepciones, las cuales no requieren la aprobación del commit. La primera es cualquier cambio que deba realizar el Ingeniero de Lanzamientos para continuar con el flujo de trabajo diario del ciclo de lanzamientos, y el segundo, son las correcciones de errores de seguridad que puedan ocurrir durante el ciclo de lanzamientos.

Una vez que la congelación de código tiene efecto, la siguiente construcción de la rama se etiqueta como BETA1. Esto se hace actualizando el valor BRANCH en sys/conf/newvers.sh de PRERELEASE a BETA1.

Una vez hecho esto, se comienza la construcción del primer conjunto BETA. Las construcciones BETA subsiguientes no requieren más actualización que la del fichero sys/conf/newvers.sh, incrementando el número de construcción BETA.

6.3. Creando la Rama releng/12.0/

Cuando la primera construcción RC (Release Candidate) está lista para comenzar, se crea la rama releng/12.0/. Este es un proceso de varios pasos que se tiene que realizar en un orden específico, para evitar anomalías como el solapado de valores de __FreeBSD_version, por ejemplo. Las rutas mostradas abajo son relativas a la raíz del repositorio. El orden de los commits y lo que hay que cambiar es el siguiente:

% svn cp ^/stable/12/ releng/12.0/
Fichero a EditarQué Cambiar

releng/12.0/sys/conf/newvers.sh

Cambia BETAX a RC1

releng/12.0/sys/sys/param.h

Actualiza __FreeBSD_version

[.filename]#releng/12.0/sys/conf/kern.opts.mk

Cambia REPRODUCIBLE_BUILD de DEFAULT_NO_OPTIONS a DEFAULT_YES_OPTIONS

releng/12.0/etc/pkg/FreeBSD.conf

Sustituye latest con quarterly para la localización por defecto del repositorio de paquetes

releng/12.0/release/pkg_repos/release-dvd.conf

Sustituye latest con quarterly para la localización por defecto del repositorio de paquetes

stable/12/sys/conf/newvers.sh

Actualiza BETAX con PRERELEASE

stable/12/sys/sys/param.h

Actualiza __FreeBSD_version

svnadmin/conf/approvers

Añade una nueva línea de validadores a la rama releng del mismo modo que se hizo para la rama stable

% svn propdel -R svn:mergeinfo releng/12.0/
% svn commit releng/12.0/
% svn commit stable/12/

Ahora que ya existe el nuevo valor de __FreeBSD_version, actualiza también ~/documentation/content/en/books/porters-handbook/versions/chapter.adoc en el repositorio del Proyecto de Documentación.

Después de que la primera construcción RC se haya completado y haya sido probada, la rama stable/ puede ser "descongelada" quitando (o comentando) la entrada ^/stable/12/ en svnadmin/conf/approvers.

Cuando la primera RC esté disponible, se debería enviar un correo a FreeBSD Bugmeister Team para añadir la nueva -RELEASE de FreeBSD a las versiones disponibles en el menú desplegable que se muestra en el gestor de bugs.

7. Construir los Medios de Instalación de FreeBSD

Esta sección describe los procedimientos generales que producen instantáneas y versiones del desarrollo de FreeBSD.

7.1. Scripts de Construcción de Versiones

Esta sección describe los scripts de construcción utilizados por FreeBSD Release Engineering Team para producir instantáneas de desarrollo y versiones.

7.1.1. El Script release.sh

Antes de la versión FreeBSD 9.0-RELEASE, se actualizó src/release/Makefile para soportar, y el script src/release/generate-release.sh fue introducido como un envoltorio, para automatizar la invocación de los distintos objetivos.

Antes de FreeBSD 9.2-RELEASE, se introdujo src/release/release.sh, que basado en gran medida en src/release/generate-release.sh incluía soporte para especificar archivos de configuración para anular varias opciones y variables de entorno. El soporte para los archivos de configuración proporcionaba soporte para construir de forma cruzada cada arquitectura para una versión especificando un archivo de configuración separado para cada invocación.

Un pequeño ejemplo de cómo usar src/release/release.sh para construir una única versión en /scratch:

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

Un breve ejemplo del uso de src/release/release.sh para construir una única versión cruzada utilizando un directorio de destino diferente, cree un release.conf personalizado que contenga:

# release.sh configuration for powerpc/powerpc64
CHROOTDIR="/scratch-powerpc64"
TARGET="powerpc"
TARGET_ARCH="powerpc64"
KERNEL="GENERIC64"

Después invoca src/release/release.sh así:

# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf

Echa un vistazo a src/release/release.conf.sample para más detalles y ejemplos de uso.

7.1.2. El Script Envoltorio thermite.sh

Para que la construcción cruzada del conjunto completo de arquitecturas soportadas en una rama determinada sea más rápida y fácil, y para reducir los factores de error humano, se escribió un script de envoltura alrededor de src/release/release.sh para iterar a través de las diversas combinaciones de arquitecturas e invocar src/release/release.sh utilizando un archivo de configuración específico para esa arquitectura.

El script de envoltura se llama thermite.sh, el cual está disponible en el repositorio Subversion de FreeBSD en svn://svn.freebsd.org/base/user/gjb/thermite/, junto con ficheros de configuración para construir las instantáneas de desarrollo de head/ y stable/12/.

El uso de thermite.sh se trata en Construyendo Instantáneas de Desarrollo de FreeBSD y Construyendo Versiones de FreeBSD.

Cada arquitectura y núcleo individual tiene su propio archivo de configuración usado por release.sh. Cada rama tiene su propia configuración defaults-X.conf, que contiene entradas comunes en cada arquitectura, donde se establecen y/o anulan las anulaciones o variables especiales en los archivos por construcción.

El esquema para nombrar los ficheros de configuración de cada construcción es de la forma ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, donde las variables en mayúsculas son equivalentes a lo que se utiliza en el sistema de construcción y las variables en minúsculas se establecen dentro de los ficheros de configuración, mapeando al número de versión mayor de la respectiva rama.

Cada rama también tiene su propia configuración builds-X.conf, que es usada por thermite.sh. El script thermite.sh itera a través de cada valor ${revision}, ${TARGET_ARCH}, ${KERNCONF}, y ${type}, creando una lista maestra de lo que hay que construir. Sin embargo, una determinada combinación de la lista sólo se construirá si existe el respectivo archivo de configuración, que es donde el esquema de denominación anterior es relevante.

Hay dos caminos para la obtención de archivos:

  • builds-12.conf - main.conf

    Este controla el comportamiento de thermite.sh

  • 12-amd64-GENERIC-snap.conf - defaults-12.conf - main.conf

    Este controla el comportamiento de release/release.sh en la construcción

Los ficheros de configuración builds-12.conf, defaults-12.conf, y main.conf existen para reducir la repetición entre los archivos de cada construcción.

7.2. Construyendo Instantáneas de Desarrollo de FreeBSD

Las máquinas de construcción de la versión oficial tienen un diseño de sistema de archivos específico, que usando ZFS, thermite.sh se aprovecha mucho con los clones y las instantáneas, asegurando un ambiente de construcción prístino.

El script de construcción se encuentra en /releng/scripts-snapshot/scripts o /releng/scripts-release/scripts respectivamente, para evitar colisiones entre una construcción RC de una rama releng y una instantánea `STABLE`de la rama estable respectiva.

Existe un conjunto separado de datos para las construcciones de las imágenes finales, /snap/ftp. Este directorio contiene los directorios tanto de las instantáneas como de las versiones. Sólo se usan si la variable EVERYTHINGISFINE está definida en main.conf.

El nombre de la variable EVERYTHINGISFINE se escogió para evitar colisiones con una variable que pudiera estar establecida en el entorno del usuario, habilitando accidentalmente el comportamiento que depende de ella al estar definida.

Conforme thermite.sh itera por la lista maestra de combinaciones y localiza el fichero de configuración de cada construcción, se crea un conjunto de datos ZFS bajo /releng, tales como /releng/12-amd64-GENERIC-snap. Los árboles src/, ports/, y `doc/`se descargan en conjuntos de datos ZFS separados, tales como /releng/12-src-snap, los cuales son clonados después y montados en sus respectivos conjuntos de datos. Esto se hace para evitar descargar un árbol más de una vez.

Asumiendo estas rutas de sistemas de archivos, thermite.sh sería invocado como:

# cd /releng/scripts-snapshot/scripts
# ./setrev.sh -b stable/12/
# ./zfs-cleanup.sh -c ./builds-12.conf
# ./thermite.sh -c ./builds-12.conf

Una vez que se han completado las compilaciones, se dispone de scripts auxiliares adicionales para generar correos electrónicos de instantáneas de desarrollo que se envían a la lista de correo freebsd-snapshots@freebsd.org:

# cd /releng/scripts-snapshot/scripts
# ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mail

La salida generada debe ser verificada dos veces para comprobar que es correcta, y el correo electrónico en sí debe ser firmado en línea mediante PGP.

Los scripts de apoyo sólo se utilizan en las construcciones de instantáneas de desarrollo. Los anuncios durante un ciclo de liberación (excepto el anuncio de la versión definitiva) se crean a partir de una plantilla de correo. Un ejemplo de la plantilla de correo que se usa actualmente se puede encontrar aquí.

7.3. Construyendo Versiones de FreeBSD

De forma similar para la construcción de instantáneas de desarrollo de FreeBSD, thermite.sh se invocaría del mismo modo. La diferencia entre instantáneas de desarrollo y construcciones de versión, BETA y RC incluidas, es que los ficheros de configuración deben utilizar el tipo release en lugar de snap como se mencionaba anteriormente.

Además, BUILDTYPE y types se deben cambiar de snap a release en defaults-12.conf y builds-12.conf, respectivamente.

Cuando se construya BETA, RC y la RELEASE final, también hay que establecer estáticamente BUILDSVNREV a la revisión de la rama que refleja el cambio de nombre, BUILDDATE a la fecha en la que las construcciones comienzan en formato YYYYMMDD. Si los árboles doc/ y ports/ han sido etiquetados, hay que establecer también PORTBRANCH y DOCBRANCH a las rutas de las etiquetas relevantes en el repositorio de Subversion, reemplazando HEAD con la última revisión. También hay que establecer releasesrc en builds-12.conf a la rama relevante, como stable/12/ o releng/12.0/.

Durante el ciclo de lanzamiento, se almacena una copia de CHECKSUM.SHA512 y CHECKSUM.SHA256 para cada arquitectura en el repositorio interno de FreeBSD Release Engineering Team además de ser incluido en varios correos electrónicos de anuncio. Cada MANIFEST que contiene los hashes de base.txz, kernel.txz, etc. es añadido también a misc/freebsd-release-manifests en la Colección de Ports.

En preparación para la construcción de la liberación, varios archivos necesitan ser actualizados:

Fichero a EditarQué Cambiar

sys/conf/newvers.sh

Actualiza el valor de BRANCH a RELEASE

UPDATING

Añade la fecha prevista del anuncio

lib/csu/common/crtbrand.S

Reemplaza __FreeBSD_version con el valor del fichero sys/sys/param.h

Después de construir la RELEASE final, la rama releng/12.0/ se etiqueta como releng/12.0/ utilizando la revisión a partir de la cual se construyó la RELEASE. De forma similar a la creación de las ramas stable/12/ y releng/12.0/, esto se hace con svn cp. Desde la raíz del repositorio:

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

8. Publicar los Medios de Instalación de FreeBSD para los Mirrors del Proyecto

Esta sección describe el procedimiento para publicar instantáneas del desarrollo de FreeBSD y las versiones en los mirrors del Proyecto.

8.1. Puesta en marcha las Imágenes de los Medios de Instalación de FreeBSD

La puesta en marcha de las instantáneas y lanzamientos de FreeBSD es un proceso de dos partes:

  • Crear la estructura de directorios que concuerda con la jerarquía en ftp-master

    Si EVERYTHINGISFINE está definida en los ficheros de configuración de la construcción, main.conf en el caso de los scripts de construcción referenciados arriba, esto sucede automáticamente después de que se haya completado la construcción, creando la estructura de directorios en ${DESTDIR}/R/ftp-stage con una estructura de rutas que concuerda con lo que se espera en ftp-master. Esto es equivalente a ejecutar directamente lo siguiente:

    # make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage

    Después de que se haya construido cada arquitectura, thermite.sh sincronizará con rsync el ${DESTDIR}/R/ftp-stage de la construcción a /snap/ftp/snapshots o /snap/ftp/releases en la máquina de construcción, respectivamente.

  • Copiar los ficheros a un directorio de preparación en ftp-master antes de mover los ficheros a pub/ para comenzar la propagación a los mirrors del Proyecto

    Una vez que todas las construcciones han terminado, /snap/ftp/snapshots, o /snap/ftp/releases para una release, es consultado por ftp-master utilizando rsync para /archive/tmp/snapshots o /archive/tmp/releases, respectivamente.

    En ftp-master en la infraestructura del Proyecto FreeBSD, este proceso necesita nivel de acceso root, ya que este paso debe ejecutarse como el usuario archive.

8.2. Publicación de los Medios de Instalación de FreeBSD

Una vez que las imágenes están preparadas en /archive/tmp/, están listas para ser publicadas poniéndolas en /archive/pub/FreeBSD. Para reducir el tiempo de propagación se crean enlaces desde /archive/tmp a /archive/pub/FreeBSD.

Para que esto sea efectivo, tanto /archive/tmp como /archive/pub deben estar en el mismo sistema de ficheros lógico.

Hay un problema, sin embargo, donde se debe usar rsync después para corregir los enlaces simbólicos en pub/FreeBSD/snapshots/ISO-IMAGES que serán reemplazados con enlaces duros, incrementando el tiempo de propagación.

Al igual que con los pasos de preparación, este requiere acceso nivel root ya que este paso debe ser ejecutado como el usuario archive.

Como usuario archive:

% cd /archive/tmp/snapshots
% pax -r -w -l . /archive/pub/FreeBSD/snapshots
% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/

Reemplaza snapshots con releases donde corresponda.

9. Cerrando el Ciclo de Liberación

En esta sección se describen las tareas generales posteriores a la liberación.

9.1. Notificaciones de Errores Posteriores a la Liberación

Según se acerca el final del ciclo de liberación, es común tener varios EN candidatos (Errata Notice) para tratar problemas que han sido descubiertos tarde en el ciclo. Después de la release, el FreeBSD Release Engineering Team y el FreeBSD Security Team revisan cambios que no fueron aprobados antes de la release final, y dependiendo del alcance del cambio en cuestión, podría crear una EN.

El proceso de creación de ENs es manejado por el FreeBSD Security Team.

Para solicitar una Errata Notice después de que el ciclo de liberación haya finalizado, un desarrollador debería rellenar el Errata Notice template, en concreto las secciones Background, Problem Description, Impact, y Workaround si es aplicable.

La plantilla completa de la Errata Notice se debería enviar junto con un parche contra releng/ o una lista de revisiones de la rama stable/.

Para peticiones de Errata Notice que sean inmediatamente posteriores a la release, la petición debería ser enviada por correo electrónico al FreeBSD Release Engineering Team y al FreeBSD Security Team. Una vez que la rama releng/ ha sido entregada al FreeBSD Security Team como se describe en Entrega al FreeBSD Security Team, las peticiones de Errata Notice deberían ser enviadas al FreeBSD Security Team.

9.2. Entrega al FreeBSD Security Team

Aproximadamente dos semanas después de la release, el Ingeniero de Liberación actualiza svnadmin/conf/approvers cambiando la columna approver de re a (so|security-officer) para la rama releng/12.0/.

10. Fin del ciclo de Vida de la Versión

Esta sección describe los ficheros que hay que actualizar en el sitio web cuando una versión alcanza su EoL (End-of-Life).

10.1. Actualizaciones del Sitio Web para End-Of-Life

Cuando un lanzamiento llega al final de su vida, las referencias a ese lanzamiento deben ser eliminadas y/o actualizadas en el sitio web:

FicheroQué Cambiar

~/website/themes/beastie/layouts/index.html

Elimina las referencias a u-relXXX-announce y u-relXXX-announce.

~/website/content/en/releases/_index.adoc

Mueve las variables u-relXXX-* desde la lista de versiones soportadas a la lista de versiones obsoletas (Legacy Releases).

~/website/content/en/releng/_index.adoc

Actualiza la rama releng apropiada para que se refleje que la rama ya no está soportada.

~/website/content/en/security/_index.adoc

Elimina la rama de la lista de ramas soportadas.

~/website/content/en/where.adoc

Elimina las URLs para la release.

~/website/themes/beastie/layouts/partials/sidenav.html

Elimina las referencias a u-relXXX-announce y u-relXXX-announce.

~/website/static/security/advisory-template.txt

Elimina las referencias a las ramas de release y releng.

~/website/static/security/errata-template.txt

Elimina las referencias a las ramas de release y releng.

Last modified on: 18 de julio de 2022 by Fernando Apesteguía