PDF de programación - Proceso de generación de releases en FreeBSD

Proceso de generación
de releases en FreeBSD

Murray Stokely <[email protected]>

Revisión: 43184

FreeBSD is a registered trademark of the FreeBSD Foundation.
CVSup is a registered trademark of John D. Polstra.
Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or regis-
tered trademarks of Intel Corporation or its subsidiaries in the United States and other coun-
tries.
XFree86 is a trademark of The XFree86 Project, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this document, and the FreeBSD
Project was aware of the trademark claim, the designations have been followed by the “™” or
the “®” symbol.

2013-11-13 07:52:45 por hrs.

Resumen
Este artículo describe la aproximación utilizada por el equipo de ingeniería de productos de
FreeBSD para generar releases de calidad y listas para utilizar en entornos de producción. Se
detalla la metodología utilizada para generar la release oficial de FreeBSD y se describen las
herramientas disponibles para aquellas personas interesadas en generar sus propias releases
a medida de sus necesidades, en particular para demostraciones de empresa o para comerciali-
zar el producto.
Traducción de Juan F. Rodriguez <[email protected] >.

Tabla de contenidos
1. Introducción ........................................................................................................................... 1
2. Proceso de ingeniería de releases ................................................................................................ 2
3. Construcción de la Release ......................................................................................................... 6
4. Distribución ............................................................................................................................ 8
5. Extensibilidad ......................................................................................................................... 9
6. Lecciones aprendidas a partir de FreeBSD 4.4 ............................................................................... 10
7. Directrices para el futuro ......................................................................................................... 10
8. Agradecimientos .................................................................................................................... 11
9. Lecturas recomendadas ............................................................................................................ 11

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
“dis” o parches) aplicados a distintas ramas de desarrollo, junto con el resto de funcionalidad que el gestor de

Proceso de ingeniería de releases

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 ex-
perimentados 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 convi-
ven 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 cam-
bios 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 ele-
tró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, “Proceso de ingeniería de releases” describe las distintas fases del proceso de ingeniería de releases
que se utiliza para construir el sistema real mientras que Sección 3, “Construcción de la Release” describe el pro-
ceso de contrucción en sí mismo. Sección 5, “Extensibilidad” describe cómo la release base puede ser ampliada por
terceras partes y Sección 6, “Lecciones aprendidas a partir de FreeBSD 4.4” detalla algunas de las lecciones apren-
didas durante la generación de la release FreeBSD 4.4. Por último, Sección 7, “Directrices para el futuro” 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

2

Proceso de generación de releases en FreeBSD

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 “co-
de 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,