
Anterior		Siguiente

2. Proceso de ingeniería de releases

Las nuevas release de FreeBSD se generan a partir de la rama -STABLE en intervalos de aproximadamente cuatro meses. El proceso comienza a ejecutarse 45 días antes de la fecha de salida, cuando el ingeniero de releases envía un correo eletrónico a las listas de desarrollo de FreeBSD para recordar a los desarrolladores que disponen de tan solo 15 días para integrar nuevos cambios antes de la fase de congelación de código fuente. Durante este periodo de tiempo, muchos desarrolladores realizan lo que se ha dado en llamar “barrido MFC”. MFC significa en inglés “Merge From CURRENT” (Integración desde CURRENT) y describe el proceso de unificación de los cambios aplicados en la rama de desarrollo -CURRENT a nuestra rama -STABLE.

2.1. Revisión de Código

Treinta días antes del lanzamiento de una release dada el repositorio de código fuente entra en una fase de “code slush” (“código aguanieve”, en el sentido de no estar aún congelado y ser por tanto ligeramente moldeable). Durante este período todos los commits de la rama -STABLE deben ser aprobados por el Grupo de ingeniería de releases <[email protected]>. Los cambios permitidos en esta fase de 15 días de duración son los siguientes:

Arreglo de bugs o errores.
Actualizaciones de la documentación.
Parches relacionados con cualquier tipo de fallo en la seguridad.
Cambios pequeños en controladores de dispositivos, tales como la adición de identificadores de dispositivo.
Cualquier cambio adicional que el equipo de ingeniería de releases considere justificado, teniendo siempre en cuenta el riesgo potencial que puede conllevar.

Después de los primeros 15 días de código “slush”, se genera una release candidate (candidata a release) o “RC” para su testeo exhaustivo por parte de la comunidad de usuarios y el código fuente entra en la fase de “code freeze” o congelamiento. En este punto resulta mucho más difícil aceptar cambios a menos que se descubran serios fallos de seguridad o bugs importantes. Durante esta fase, se genera al menos una RC cada semana, hasta que la release final ve la luz. Durante el periodo de tiempo comprendido desde el congelamiento del código hasta la generación de la release final, el equipo de ingeniería de releases se comunica constantemente con el equipo del “security officer”, los equipos encargados de mantener la documentación y los mantenedores de ports, para asegurarse de que los distintos componentes necesarios para obtener una release existosa se encuentran disponibles y listos para ser construidos.

2.2. Lista de tareas para la release final.

Cuando todos los problemas encontrados en las releases candidatas se han corregido, se puede comenzar con el procedimiento de “pulimiento o enbellecimiento” de la release final.

2.2.1. Creación de una Rama Release

Como se describe en la introducción, la rama RELENG_X_Y es una característica relativamente nueva de nuestra metodología de generación de releases. El primer paso para crear esta rama consiste en asegurar que el código fuente utilizado “proviene” de la versión más reciente de RELENG_X.

/usr/src# cvs update -rRELENG_4 -P -d

El siguiente paso consiste en crear una etiqueta de rama, (tag), de esta forma se pueden generar diferencias entre el código actual y la rama de inicio fácilmente, utilizando CVS:

/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src

Y a continuación se crea la etiqueta de la rama:

/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src

Nota: Las etiquetas RELENG_* sólo pueden ser utilizadas por los CVS-meisters y los ingenieros de releases.

2.2.2. Elevación del número de versión

Antes de que la release final se puede etiquetar, construir y antes de que vea la luz, se deben modificar los siguientes ficheros de tal forma que reflejen el número de versión correcto:

doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml
doc/en_US.ISO8859-1/books/porters-handbook/book.xml
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/share/examples/cvsup/standard-supfile
src/sys/conf/newvers.sh
src/sys/sys/param.h
src/usr.sbin/pkg_install/add/main.c
www/en/docs.xml
www/en/cgi/ports.cgi
ports/Tools/scripts/release/config

El fichero “release notes” y el fichero “errata” también deben ajustarse de acuerdo con la nueva release (en la rama de la release) y deben cortarse adecuadamente en las ramas stable/currrent):

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

Sysinstall debe actualizarse para que proporcione el número actual de ports disponibles y la cantidad de espacio de disco requerida para instalar dicha colección de ports. Esta información se encuentra almacenada actualmente en el fichero src/release/sysinstall/dist.c.

Después de construir la release se debe actualizar el número almacenado en los siguientes ficheros para anunciar la release al resto del mundo:

www/share/xml/includes.release.xml
www/share/xml/includes.release.xsl
www/en/releases/*
www/en/releng/index.xml
www/en/news/news.xml
www/en/search/web.atoz
src/share/misc/bsd-family-tree

2.2.3. Creación de las etiquetas de release

Cuando la release final se encuentra preparada se utiliza el siguiente comando para crear la etiqueta (a modo de ejemplo) RELENG_4_8_0_RELEASE.

/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src

Los gestores de los proyectos de Documentación y de los Ports se responsabilizan del correcto etiquetado de sus respectivos árboles utilizando RELEASE_4_8_0.

Ocasionalmente se puede presentar un apaño o arreglo de última hora justo después de la creación de las etiquetas finales. En la práctica esto no constituye un problema ya que CVS permite cierta manipulación de etiquetados mediante cvs tag -d nombredeetiqueta nombredefichero . Es muy importante que dichos cambios de última hora se etiqueten adecuadamente para que pasen a formar parte de la nueva release. Las releases de FreeBSD deben ser siempre “reproducibles”. Los “hacks” locales dentro del entorno de ingeniería de releases no están permitidos salvo que se efectúen mediante una correcta manipulación y notificación.