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 comercializar el producto.
Traducción de Juan F. Rodriguez <jrh@it.uc3m.es>.
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, “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 proceso 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 aprendidas durante la generación de la release FreeBSD 4.4. Por último, Sección 7, “Directrices para el futuro” presenta caminos futuros de desarrollo.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.