Proceso de generación de releases en FreeBSD

1. Introducción

El desarrollo de FreeBSD es un proceso realmente abierto al público. FreeBSD se alimenta de contribuciones de miles de personas del mundo entero. El Proyecto FreeBSD proporciona acceso público a través de CVS[1] de tal forma que cualquiera puede acceder a los mensajes de log y a los archivos de diferencias (también conocidos como “diffs” o parches) aplicados a distintas ramas de desarrollo, junto con el resto de funcionalidad que el gestor de código fuente pone a nuestra disposición. Este hecho, aunque muchas veces pasa inadvertido, ha constituido uno de los más importantes recursos de la comunidad y ha servido para captar y motivar a muchos desarrolladores con talento. No obstante, y creo que todo el mundo está de acuerdo con lo que voy a decir, sería un completo caos proporcionar acceso de escritura a todo el que pueda conectarse a Internet. Es por esto que existe sólo un “selecto” grupo de en torno a 300 personas que poseen dicho acceso de escritura en el repositorio de CVS. Estos committers[6] se responsabilizan del desarrollo del corazón de FreeBSD. Un core-team[7] compuesto por desarrolladores muy experimentados proporciona ciertas directrices a la dirección que va a tomar el proyecto.

El rápido ritmo de desarrollo de FreeBSD deja poco tiempo para pulir el sistema y proporcionar una release de calidad equivalente a las releases de sistemas comerciales. Para resolver este problema, se continúa el desarrollo en dos caminos paralelos. La rama de desarrollo principal se denomina HEAD o trunk (tronco) y constituye el punto de desarrollo más avanzado del árbol CVS. Esta rama consituye lo que llamamos “FreeBSD-CURRENT” o simplemente “-CURRENT” para abreviar.

También se mantiene una rama más estable, conocida como “FreeBSD-STABLE” o “-STABLE”. Ambas ramas conviven en el repositorio maestro de CVS localizado en California y dicho repositorio se replica vía CVSup[2] creandose una serie de réplicas (también llamadas espejos o mirrors) por todo el mundo. FreeBSD-CURRENT[8] consituye el límite tecnológico (o “bleeding-edge” en inglés) del desarrollo del sistema FreeBSD y es donde se aplican en primer lugar cualquier cambio realizado al sistema. FreeBSD-STABLE constituye la rama de desarrollo de la cual se generan las releases principales. Los cambios en el sistema se producen a un ritmo variable asumiendose que dichos cambios generalmente se aplican primero a la rama -CURRENT, quedando a disposición de la comunidad de usuarios para que comprueben el correcto funcionamiento global del sistema de una forma exhaustiva antes de aplicarlos a -STABLE, en caso de que fuera necesaria su aplicación.

En el periodo entre releases, se construyen copias del sistema tomadas a determinadas horas de la noche y se ponen a disposición del público en ftp://stable.FreeBSD.org/. La amplia disponibilidad de releases de copias binarias actualizadas del sistema (“snapshosts”) y la tendencia de nuestra comunidad de usuarios a mantenerse a la última del desarrollo en la rama -STABLE mediante la utilización de CVSup y “make world”[8] ayuda a mantener la rama FreeBSD-STABLE en unas condiciones de fiabilidad excelentes que incluso llegan a ralentizar las peticiones de nuevas releases basadas en actividades de depuración de la calidad del software.

Los informes de problemas y las solicitudes de nuevas características no paran de producirse durante el ciclo de vida de una release. Los informes de problemas se almacenan en la base de datos GNATS[9] utilizando el correo eletrónico, la aplicación send-pr(1) o vía la interfaz web proporcionada en http://www.FreeBSD.org/send-pr.html. Además de la multitud de listas de correo de carácter técnico que FreeBSD pone a nuestra disposición, el lista de correo sobre 'Quality Assurance' en FreeBSD proporciona un foro de discusión sobre aspectos “a pulir” del sistema antes de su salida.

Para dar servicio a nuestro usuarios más conservadores, con la aparición de FreeBSDD 4.3 se introdujeron ramas individuales dentro del árbol CVS. Estas ramas de releases se crean poco tiempo después de la generación de una release final. Una vez generada la última release (la más actual o más reciente), sólo se aplican a esta release las modificaciones más críticas o necesarias, normalmente aquellas que provienen de fallos de seguridad. Además de las actualizaciones del código fuente a través de CVS, existen paquetes de parches binarios para mantener las releases RELENG_X_Y actualizadas.

La Sección 2 describe las distintas fases del proceso de ingeniería de releases que se utiliza para construir el sistema real mientras que Sección 3 describe el proceso de contrucción en sí mismo. Sección 5 describe cómo la release base puede ser ampliada por terceras partes y Sección 6 detalla algunas de las lecciones aprendidas durante la generación de la release FreeBSD 4.4. Por último, Sección 7 presenta caminos futuros de desarrollo.

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.

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

/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src

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

/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src

3. Construcción de la Release

Cualquier persona dueña de una potente máquina y con acceso de lectura al repositorio de código fuente puede “construir” las “releases” de FreeBSD. En la práctica esto significa que cualquiera puede generar el proceso de construcción de releases, ya que, como se comentó con anterioridad, FreeBSD ofrece acceso CVS anónimo a todo el mundo (consulte el Handbook para más detalles). El único requisito imprescindible para realizar este proceso es la existencia del dispositivo vn(4). (En -CURRENT, este dispositivo ha sido reemplazado por el nuevo driver de discos en memoria denominado md(4).) Si el dispositivo no se encuentra cargado en el kernel, debería cargarse automáticamente al ejecutar el comando vnconfig(8) como parte de la fase de creación del medio de arranque. Todas las herramientas necesarias para construir la release se encuentran disponibles en el repositorio de CVS dentro del directorio src/release. Estas herramientas proporcionan una forma consistente y robusta de construir releases de FreeBSD. Una release completa se puede construir utilizando un único comando, incluyendo la creación de las imágenes ISO necesarias para realizar copias en CDROM, junto con disquetes de instalación y un directorio para la instalación por FTP. Este comando fue adecuadamente bautizado como make release.

make release CHROOTDIR=/local3/release \
       BUILDNAME=4.7-RELEASE \
       CVSROOT=/host/cvs/usr/home/ncvs \
       RELEASETAG=RELENG_4_7_0_RELEASE
       
    

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

4. Distribución

5. Extensibilidad

Aunque FreeBSD consitituye un sistema operativo “completo”, no existe nada que nos obligue a utilizarlo exactamente igual que como se ha empaquetado para crear la distribución. Es decir, el sistema FreeBSD se ha diseñado para ser tan extensible como sea posible de tal forma que se puede utilizar como la base sobre la que se pueden construir productos comerciales. La única “regla” sobre este tema es que si se piensa distribuir FreeBSD con una serie de cambios profundos en él , se anima a que se documenten adecuadamente dichos mejoras. La comunidad FreeBSD sólo puede ayudar a los usuarios que utilizan el software que dicha comunidad distribuye. Se anima encarecidamente hacia la innovación tanto en el proceso de instalación como en las herramientas de administración, pero no se puede esperar un respuesta a todas las preguntas que surgan sobre dichos temas.

6. Lecciones aprendidas a partir de FreeBSD 4.4

El proceso de ingeniería de releases de FreeBSD 4.4 comenzó formalmente el 1 de Agosto de 2001. Después de esa fecha todos los “commits” o modificaciones sobre la rama RELENG_4 de FreeBSD tuvieron que ser aprobados explícitamente por el Grupo de ingeniería de releases <re@FreeBSD.org>. La primera “release candidate” para la arquitectura x86 apareció el 16 de Agosto, seguida por otras cuatro releases candidatas hasta que vió la luz la release final el 18 de Septiembre. El “security officer” estuvo muy involucrado en la última semana del proceso ya que se descubrieron varios problemas de seguridad en las “release candidates” iniciales. Más de 500 correos electrónicos fueron enviados al Grupo de ingeniería de releases <re@FreeBSD.org> en poco más de un mes.

Nuestra comunidad de usuarios ha dejado muy claro que la seguridad y estabilidad de las releases de FreeBSD no pueden sacrificarse por culpa de plazos autoimpuestos o fechas de lanzamiento. El Proyecto FreeBSD ha crecido tremendamente durante su tiempo de vida y se ha visto claramente la necesidad de estandarizar los procedimientos de ingeniería de releases. Este hecho será incluso más importante a medida que FreeBSD vaya estando disponible para más plataformas.

7. Directrices para el futuro

Es de vital importancia para nuestras actividades de ingeniería de releases el ser capaces de crecer al mismo ritmo que nuestra base de usuarios. Junto con estas líneas estamos trabajando duramente en los procedimientos involucrados en la producción de releases de FreeBSD.

• Paralelismo - Algunas partes de la construcción de la release son “vergonzosamente paralelas”. La mayoría de las tareas que se realizan son intensivas en entrada-salida, de tal forma que resulta más importante poseer varios discos duros de alta velocidad que utilizar varios procesadores a la hora de acelerar el proceso del comando make release. Si se utilizan varios discos para las distintas jerarquías de directorios dentro del entorno chroot(2), entonces el “checkout” de los árboles de ports y de los doc se puede producir al mismo tiempo que la ejecución en otro disco del comando make world. Mediante la utilización de un sistema RAID (hardware o software) se puede reducir significativamente el tiempo total de construcción de la release.

• Releases construidas para otros sistemas finales (“cross building”) : ?Se puede construir una release para IA-64 o Alpha en un hardware x86? make TARGET=ia64 release.

• Tests de Regresión - Se necesitan mejores herramientas automatizadas para comprobar la corrección del sistema FreeBSD.

• Herramientas de Instalación - Nuestro programa de instalación ha sobrepasado su tiempo de vida previsto. Se encuentran en desarrollo varios proyectos para proporcionar un mecanismo de instalación más avanzado. Uno de los más prometedores es el proyecto libh[5] cuyo objetivo consiste en proporcionar un entorno de paquetes nuevo e inteligente junto con un programa de instalación gráfico.

8. Agradecimientos

Me gustaría agradecer a Jordan Hubbard por darme la oportunidad de colaborar en algunas de las responsabilidades del equipo de ingeniería de releases en FreeBSD 4.4 y también me gustaría agradecer públicamente su trabajo y dedicación durante todos estos años para poder situar a FreeBSD en el sitio de honor que le corresponde hoy día. Por supuesto que la release 4.4 no hubiera visto la luz sin el trabajo de 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> y del resto de la comunidad FreeBSD. También me gustaría agradecer especialmente a Rodney Grimes <rgrimes@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org> y muchos otros que trabajaron en las herramientas de ingeniería de releases en los comienzos del sistema FreeBSD. Este artículo está basado en documentos de ingeniería de releases del CSRG[14], el NetBSD Project[11] y en las notas del proceso de ingeniería de releases propuestas por John Baldwin[12].

9. Lecturas recomendadas

[1] CVS - Concurrent Versions System http://www.cvshome.org

[2] CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup

[3] http://bento.FreeBSD.org

[4] FreeBSD Ports Collection http://www.FreeBSD.org/ports

[5] The libh Project http://www.FreeBSD.org/projects/libh.html

[6] FreeBSD Committers http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html

[7] FreeBSD Core-Team http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-core.html

[8] FreeBSD Handbook http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook

[9] GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats

[10] FreeBSD PR Statistics http://www.FreeBSD.org/prstats/index.html

[11] NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html

[12] John Baldwin's FreeBSD Release Engineering Proposal http://people.FreeBSD.org/~jhb/docs/releng.txt

[13] PXE Jumpstart Guide http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html

[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD