                  Proceso de generacion de releases en FreeBSD

  Murray Stokely

   <murray@FreeBSD.org> http://www.FreeBSD.org/~murray/
    

   Revision: 8def749c53

   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 registered trademarks of Intel Corporation or its
   subsidiaries in the United States and other countries.

   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 "(TM)" or the "(R)"
   symbol.

   2013-11-13 07:52:45 +0000 por Hiroki Sato.
   Resumen

   Este articulo describe la aproximacion utilizada por el equipo de
   ingenieria de productos de FreeBSD para generar releases de calidad y
   listas para utilizar en entornos de produccion. Se detalla la metodologia
   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.

   Traduccion de Juan F. Rodriguez <jrh@it.uc3m.es>.

   [ Split HTML / Single HTML ]

     ----------------------------------------------------------------------

   Tabla de contenidos

   1. Introduccion

   2. Proceso de ingenieria de releases

   3. Construccion de la Release

   4. Distribucion

   5. Extensibilidad

   6. Lecciones aprendidas a partir de FreeBSD 4.4

   7. Directrices para el futuro

   8. Agradecimientos

   9. Lecturas recomendadas

1. Introduccion

   El desarrollo de FreeBSD es un proceso realmente abierto al publico.
   FreeBSD se alimenta de contribuciones de miles de personas del mundo
   entero. El Proyecto FreeBSD proporciona acceso publico a traves de CVS[1]
   de tal forma que cualquiera puede acceder a los mensajes de log y a los
   archivos de diferencias (tambien conocidos como "diffs" o parches)
   aplicados a distintas ramas de desarrollo, junto con el resto de
   funcionalidad que el gestor de codigo fuente pone a nuestra disposicion.
   Este hecho, aunque muchas veces pasa inadvertido, ha constituido uno de
   los mas 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 esta de acuerdo con lo que voy a decir, seria un completo caos
   proporcionar acceso de escritura a todo el que pueda conectarse a
   Internet. Es por esto que existe solo 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 corazon de
   FreeBSD. Un core-team[7] compuesto por desarrolladores muy experimentados
   proporciona ciertas directrices a la direccion que va a tomar el proyecto.

   El rapido 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 continua el
   desarrollo en dos caminos paralelos. La rama de desarrollo principal se
   denomina HEAD o trunk (tronco) y constituye el punto de desarrollo mas
   avanzado del arbol CVS. Esta rama consituye lo que llamamos
   "FreeBSD-CURRENT" o simplemente "-CURRENT" para abreviar.

   Tambien se mantiene una rama mas estable, conocida como "FreeBSD-STABLE" o
   "-STABLE". Ambas ramas conviven en el repositorio maestro de CVS
   localizado en California y dicho repositorio se replica via CVSup[2]
   creandose una serie de replicas (tambien llamadas espejos o mirrors) por
   todo el mundo. FreeBSD-CURRENT[8] consituye el limite tecnologico (o
   "bleeding-edge" en ingles) 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 disposicion 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 aplicacion.

   En el periodo entre releases, se construyen copias del sistema tomadas a
   determinadas horas de la noche y se ponen a disposicion del publico 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 ultima del desarrollo en la rama
   -STABLE mediante la utilizacion 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 depuracion de la calidad del software.

   Los informes de problemas y las solicitudes de nuevas caracteristicas 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 eletronico, la aplicacion send-pr(1) o via la interfaz web
   proporcionada en http://www.FreeBSD.org/send-pr.html. Ademas de la
   multitud de listas de correo de caracter tecnico que FreeBSD pone a
   nuestra disposicion, el lista de correo sobre 'Quality Assurance' en
   FreeBSD proporciona un foro de discusion sobre aspectos "a pulir" del
   sistema antes de su salida.

   Para dar servicio a nuestro usuarios mas conservadores, con la aparicion
   de FreeBSDD 4.3 se introdujeron ramas individuales dentro del arbol CVS.
   Estas ramas de releases se crean poco tiempo despues de la generacion de
   una release final. Una vez generada la ultima release (la mas actual o mas
   reciente), solo se aplican a esta release las modificaciones mas criticas
   o necesarias, normalmente aquellas que provienen de fallos de seguridad.
   Ademas de las actualizaciones del codigo fuente a traves de CVS, existen
   paquetes de parches binarios para mantener las releases RELENG_X_Y
   actualizadas.

   La Seccion 2, "Proceso de ingenieria de releases" describe las distintas
   fases del proceso de ingenieria de releases que se utiliza para construir
   el sistema real mientras que Seccion 3, "Construccion de la Release"
   describe el proceso de contruccion en si mismo. Seccion 5,
   "Extensibilidad" describe como la release base puede ser ampliada por
   terceras partes y Seccion 6, "Lecciones aprendidas a partir de FreeBSD
   4.4" detalla algunas de las lecciones aprendidas durante la generacion de
   la release FreeBSD 4.4. Por ultimo, Seccion 7, "Directrices para el
   futuro" presenta caminos futuros de desarrollo.

2. Proceso de ingenieria 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 dias antes de la fecha de salida, cuando el ingeniero de
   releases envia un correo eletronico a las listas de desarrollo de FreeBSD
   para recordar a los desarrolladores que disponen de tan solo 15 dias para
   integrar nuevos cambios antes de la fase de congelacion de codigo fuente.
   Durante este periodo de tiempo, muchos desarrolladores realizan lo que se
   ha dado en llamar "barrido MFC". MFC significa en ingles "Merge From
   CURRENT" (Integracion desde CURRENT) y describe el proceso de unificacion
   de los cambios aplicados en la rama de desarrollo -CURRENT a nuestra rama
   -STABLE.

  2.1. Revision de Codigo

   Treinta dias antes del lanzamiento de una release dada el repositorio de
   codigo fuente entra en una fase de "code slush" ("codigo aguanieve", en el
   sentido de no estar aun congelado y ser por tanto ligeramente moldeable).
   Durante este periodo todos los commits de la rama -STABLE deben ser
   aprobados por el Grupo de ingenieria de releases <re@FreeBSD.org>. Los
   cambios permitidos en esta fase de 15 dias de duracion son los siguientes:

     * Arreglo de bugs o errores.

     * Actualizaciones de la documentacion.

     * Parches relacionados con cualquier tipo de fallo en la seguridad.

     * Cambios pequenos en controladores de dispositivos, tales como la
       adicion de identificadores de dispositivo.

     * Cualquier cambio adicional que el equipo de ingenieria de releases
       considere justificado, teniendo siempre en cuenta el riesgo potencial
       que puede conllevar.

   Despues de los primeros 15 dias de codigo "slush", se genera una release
   candidate (candidata a release) o "RC" para su testeo exhaustivo por parte
   de la comunidad de usuarios y el codigo fuente entra en la fase de "code
   freeze" o congelamiento. En este punto resulta mucho mas dificil 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 codigo hasta la generacion de la
   release final, el equipo de ingenieria de releases se comunica
   constantemente con el equipo del "security officer", los equipos
   encargados de mantener la documentacion 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. Creacion de una Rama Release

   Como se describe en la introduccion, la rama RELENG_X_Y es una
   caracteristica relativamente nueva de nuestra metodologia de generacion de
   releases. El primer paso para crear esta rama consiste en asegurar que el
   codigo fuente utilizado "proviene" de la version mas 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 codigo actual y la rama de
   inicio facilmente, utilizando CVS:

 /usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src

   Y a continuacion se crea la etiqueta de la rama:

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

  Nota:

   Las etiquetas RELENG_* solo pueden ser utilizadas por los CVS-meisters y
   los ingenieros de releases.

   Una "etiqueta o tag" es una caracteristica de CVS que sirve para
   identificar el codigo fuente en un determinado instante del tiempo.
   Mediante el etiquetado del arbol, nos aseguramos de que las futuras
   releases puedan generar diferencias con respecto al mismo codigo fuente
   que se utilizo para generar las releases oficiales anteriores.

                 Rama FreeBSD Development (Rama de Desarrollo)
                            Rama FreeBSD 3.x STABLE
                            Rama FreeBSD 4.x STABLE

    2.2.2. Elevacion del numero de version

   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 numero de version 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" tambien 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 numero actual de
   ports disponibles y la cantidad de espacio de disco requerida para
   instalar dicha coleccion de ports. Esta informacion se encuentra
   almacenada actualmente en el fichero src/release/sysinstall/dist.c.

   Despues de construir la release se debe actualizar el numero 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. Creacion 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 Documentacion y de los Ports se
   responsabilizan del correcto etiquetado de sus respectivos arboles
   utilizando RELEASE_4_8_0.

   Ocasionalmente se puede presentar un apano o arreglo de ultima hora justo
   despues de la creacion de las etiquetas finales. En la practica esto no
   constituye un problema ya que CVS permite cierta manipulacion de
   etiquetados mediante cvs tag -d nombredeetiqueta nombredefichero . Es muy
   importante que dichos cambios de ultima 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 ingenieria de releases no estan permitidos salvo que se efectuen
   mediante una correcta manipulacion y notificacion.

3. Construccion de la Release

   Cualquier persona duena de una potente maquina y con acceso de lectura al
   repositorio de codigo fuente puede "construir" las "releases" de FreeBSD.
   En la practica esto significa que cualquiera puede generar el proceso de
   construccion de releases, ya que, como se comento con anterioridad,
   FreeBSD ofrece acceso CVS anonimo a todo el mundo (consulte el Handbook
   para mas detalles). El unico 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,
   deberia cargarse automaticamente al ejecutar el comando vnconfig(8) como
   parte de la fase de creacion 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 unico
   comando, incluyendo la creacion de las imagenes ISO necesarias para
   realizar copias en CDROM, junto con disquetes de instalacion y un
   directorio para la instalacion por FTP. Este comando fue adecuadamente
   bautizado como make release.

  3.1. make release

   Para poder construir la releases de una forma exitosa se debe rellenar
   primero el directorio /usr/obj ejecutando el comando make world o
   simplemente make buildworld. El target release que utiliza el comando make
   necesita varias variables, tal como se muestra a continuacion:

     * CHROOTDIR - El directorio que se utiliza para el entorno de chroot
       durante la construccion de la release entera.

     * BUILDNAME - El nombre de la release que se va a construir.

     * CVSROOT - La ubicacion del repositorio de CVS.

     * RELEASETAG - La etiqueta CVS correspondiente con la release que se
       quiere construir.

   Si no se dispone de acceso a un repositorio de CVS local, se puede
   realizar una copia espejo (un mirror) con CVSup. El fichero
   /usr/share/examples/cvsup/cvs-supfile, sirve como buen punto de partida
   para realizar un mirror del repositorio de CVS.

   Si se omite RELEASETAG, la release se construira a partir de la rama HEAD
   (tambien conocida como -CURRENT). Las releases que se construyen desde el
   principio se conocen normalmente con el nombre de "-CURRENT snapshots".

   Existen otras variables que se pueden editar para adaptar el proceso de
   construccion de la release. La mayoria de estas variables se encuentran
   documentadas al comienzo de src/release/Makefile. El comando exacto para
   contruir la release oficial de FreeBSD 4.7 (x86) fue:

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

   El Makefile de la release se puede dividir en varios pasos distintos.

     * Creacion de un entorno de sistema limpio en una jerarquia de
       directorios separada utilizando "make installworld".

     * Comprobacion de la correcta version de los ficheros fuentes
       almacenados en la jerarquia de directorios recien creada, junto con el
       chequeo de la documentacion y de los ports utilizando, todo ello a
       traves de CVS.

     * Relleno de los directorios /etc y /dev dentro del entorno chroot.

     * Creacion de un "chroot" dentro de la jerarquia de directorios creada,
       para que resulte mas dificil que el entorno de la maquina se vea
       contaminado por la construccion de la release.

     * make world dentro del entorno de chroot.

     * Contruccion de los binarios relacionados con Kerberos.

     * Construccion del kernel GENERIC.

     * Creacion de un esqueleto del arbol de directorios donde se construiran
       y empaquetaran las distribuciones binarias.

     * Construccion e instalacion del conjunto de herramientas de
       documentacion necesarias para convertir los fuentes de la
       documentacion (SGML) en los documentos HTML y de texto que pasaran a
       formar parte de la release.

     * Construccion e instalacion de la documentacion real (manuales de
       usuario, tutoriales, release notes, listas de compatibilidad de
       hardware, etc.)

     * Construccion de los "decisivos" binarios utilizados en los disquetes
       de instalacion.

     * Colocacion adecuada de los de los paquetes de distribucion de binarios
       y de fuentes.

     * Creacion del medio de arranque y del disquete "fixit" o salvamento.

     * Creacion de la jerarquia de directorios de instalacion por FTP.

     * Creacion de imagenes ISO para CDROM/DVD(opcional).

   Para mas informacion sobre la infraestructura involucrada en el proceso de
   construccion de la release, el lector puede consultar release(7).

  3.2. Construccion deXFree86(TM)

   XFree86(TM) es un componente importante para muchos usuarios de entornos
   graficos. Antes de la release FreeBSD 4.6 las se usaba XFree86(TM)3.X por
   defecto. La forma mas sencilla de construir estas versiones consiste en
   utilizar el script src/release/scripts/X11/build_x.sh. Este script
   requiere que XFree86(TM) y Tcl/Tk se encuentren instalados previamente en
   la maquina donde se realiza la construccion. Despues de compilar los
   servidores X necesarios, el script empaqueta todos los ficheros en
   "tarballs" que sysinstall(8) sabe como localizar utilizando el directorio
   XF86336 del medio de instalacion.

   A partir de FreeBSD 4.6, sysinstall(8) instala XFree86(TM) 4.X por
   defecto, como cualquier otro conjunto de paquetes. Estos paquetes se
   pueden construir a partir del "package-building cluster" o a partir de las
   etiquetas del arbol de ports adecuadas.

  Nota:

   Es importante borrar cualquier configuracion particular almacenada en
   /etc/make.conf. Por ejemplo, no seria una idea muy inteligente distribuir
   binarios que se construyeron en un sistema con la variable CPUTYPE
   asignada a un determinado procesador.

  3.3. Software Contribuido ("ports")

   La coleccion de FreeBSD Ports esta compuesta por mas de 24,000 paquetes de
   software de terceras partes que se encuentran disponibles para FreeBSD. El
   Grupo de administracion de ports <portmgr@FreeBSD.org> se responsabiliza
   de mantener un arbol de ports consistente que se pueda utilizar para crear
   paquetes binarios, los cuales se anaden a las releases oficiales de
   FreeBSD.

   Las actividades de ingenieria de releases para nuestra coleccion de
   paquetes software de terceras partes se encuentra mas alla del objetivo de
   este documento. Otro articulo,
   http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/,
   cubre este tema en profundidad.

  3.4. ISOs de la release

   A partir de FreeBSD 4.4, el Proyecto FreeBSD decidio lanzar gratuitamente
   al publico las cuatro imagenes ISO que anteriormente se vendian en
   BSDi/Wind River Systems/FreeBSD Mall como distribuciones en CDROM
   "oficiales". Cada uno de los cuatro discos debe contener un README.TXT que
   explica el contenido de cada disco, un CDROM.INF que proporciona metadatos
   para que sysinstall(8) pueda validar la informacion en el contenida y un
   filename.txt que proporciona un "manifiesto". Este manifiesto se puede
   crear utilizando un simple comando:

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

   Los requisitos concretos de cada CD se resumen a continuacion.

    3.4.1. Disco 1

   El primer disco se crea casi en su totalidad a partir del comando make
   release. Los unicos cambios que se deben realizar dentro del directorio
   disc1 son la adicion de un directorio tools, de XFree86(TM) y de los
   paquetes de terceras partes mas populares que quepan dentro del espacio
   remanente de dicho primer disco. El directorio tools contiene el software
   que permite a los usuarios crear disquetes de instalacion desde otros
   sistemas operativos. Este disco debe crearse como autoarrancable para que
   los usuarios de PCs modernos no necesiten crear disquetes de arranque y
   puedan utilizar la caracteristica de autoarranque desde CD.

   Si se proporciona una version alternativa de XFree86(TM), sysinstall(8)
   debe actualizarse para reflejar la nueva localizacion y las instrucciones
   de instalacion. El codigo relevante se encuentra en src/release/sysinstall
   en -STABLE o en src/usr.sbin/sysinstall en -CURRENT. Especificamente, se
   deben actualizar dist.c, menus.c y config.c.

    3.4.2. Disco 2

   El segundo disco se crea en su mayor parte a partir del comando make
   release. Este disco contiene un "sistema de ficheros vivo", que se puede
   utilizar a partir de sysinstall(8) para resolver problemas durante el
   proceso de instalacion de FreeBSD. Este disco se debe construir como
   autoarrancable y debe contener una copia comprimida del repositorio de CVS
   dentro del directorio CVSROOT, junto con demostraciones de software
   comercial localizadas dentro del directorio commerce.

    3.4.3. Discos 3 and 4

   Los dos discos que quedan contienen paquetes de software para FreeBSD.
   Estos paquetes deben agruparse de tal forma que un paquete y todas sus
   dependencias quepan en el mismo disco. Se puede obtener mas informacion
   sobre la creacion de estos discos en el articulo
   http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/ .

4. Distribucion

  4.1. Servidores de FTP

   Cuando se ha probado exhaustivamente la release y se ha empaquetado
   debidamente para proceder a su distribucion, se debe actualizar el sitio
   maestro de FTP. Los sitios FTP oficiales de FreeBSD son mirrors del sitio
   FTP maestro, tambien llamado ftp-master. Cuando la release esta lista, se
   deben modificar los siguientes ficheros en el servidor ftp-master:

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/

           El directorio de instalacion dde FTP que se crea con la salida del
           comando make release.

   /pub/FreeBSD/ports/arch/packages-X.Y-release/

           La construccion del paquete completo de la release.

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools

           Un enlace simbolico a ../../../tools.

   /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages

           Un enlace simbolico a ../../../ports/arch/packages-X.Y-release.

   /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso

           Las imagenes ISO. El "*" se sustituye por disc1, disc2, etc. Solo
           si existe disc1 junto con un CD de primera instalacion alternativo
           (por ejemplo una instalacion recortada o reducida sin sistema de
           ventanas) puede existir tambien un mini.

   Para obtener mas informacion sobre la arquitectura de mirrors para la
   distribucion del sistema FreeBSD, se ruega al lector que consulte el
   articulo Mirroring FreeBSD.

   Puede que transcurran desde varias horas hasta varios dias hasta que la
   mayoria de los sitios FTP Tier-1 se actualicen con respecto al ftp-master,
   esto depende de si un determinado paquete se cargo o no se cargo en
   determinado instante. Es imperativo que los ingenieros de releases se
   coordinen con lista de correo de avisos para administradores de replicas
   de FreeBSD antes de anunciar la disponibilidad general del nuevo software
   en los sitios FTP. Para que todo fuera bien el paquete de la release se
   deberia cargar al menos cuatro dias antes del dia oficial de lanzamiento
   de la release. Los permisos para el grupo "other" deben desactivarse
   completamente para que los sitios espejos puedan descargar la release pero
   no asi los usuarios finales, hasta que llegue el dia oficial del
   lanzamiento. Se debe enviar un correo a lista de correo de avisos para
   administradores de replicas de FreeBSD cuando se publican la release con
   los permisos modificados, diciendo que la release ha sido puesta en escena
   y proporcionando la fecha a partir de la cual los mirrors deben comenzar a
   dar permisos de acceso para el publico en general. Se debe comprobar que
   se incluye informacion relativa a zonas horarias, por ejemplo informacion
   relativa a GMT.

  4.2. Replicacion de CD-ROMs

   Dentro de poco tiempo: Consejos para enviar ISOs de FreeBSD a un
   replicador e informacion sobre las medidas de aseguramiento de la calidad
   que se deben tomar.

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 distribucion. Es decir, el sistema FreeBSD se ha disenado
   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 unica "regla" sobre este tema es que si se piensa
   distribuir FreeBSD con una serie de cambios profundos en el , se anima a
   que se documenten adecuadamente dichos mejoras. La comunidad FreeBSD solo
   puede ayudar a los usuarios que utilizan el software que dicha comunidad
   distribuye. Se anima encarecidamente hacia la innovacion tanto en el
   proceso de instalacion como en las herramientas de administracion, pero no
   se puede esperar un respuesta a todas las preguntas que surgan sobre
   dichos temas.

  5.1. Creacion de disquetes de arranque a medida

   Muchas organizaciones poseen complejos requisitos que pueden consistir en
   modulos del kernel adicionales o herramientas de entorno de usuario que
   deben anadirse en los discos de instalacion. La forma "rapida y sucia" de
   anadir estas cosas consiste en modificar el directorio temporal que
   contiene la estructura de un make release:

     * Aplicar parches o anadir archivos adicionales dentro del directorio
       chroot de construccion de la release.

     * rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59]

     * Reconstruir sysinstall(8), el kernel o cualquier otra parte del
       sistema que se vea afectada por los cambios.

     * chroot ${CHROOTDIR} ./mk floppies

   Los nuevos disquetes de instalacion estaran en
   ${CHROOTDIR}/R/stage/floppies.

   Tambien se puede llamar el objetivo de make boot.flp o directamente al
   "script" de creacion del sistema de ficheros src/release/scripts/doFS.sh.

   Los parches locales tambien se pueden proporcionar al proceso de
   construccion de la release mediante la definicion de la variable
   LOCAL_PATCH dentro de make release.

  5.2. "Scripts" para sysinstall

   La instalacion y configuracion del sistema FreeBSD a traves de
   sysinstall(8) se puede modificar mediante "scripts" para que proporcione
   instalaciones automaticas a grandes organizaciones. Esta funcionalidad se
   puede utilizar conjuntamente con Intel(R) PXE[13] para arrancar sistemas a
   traves de la red, o a traves de disquetes de arranque a medida utilizando
   un "script" de sysinstall. Un ejemplo de guion sysinstall se encuentra
   disponible en src/release/sysinstall/install.cfg.

6. Lecciones aprendidas a partir de FreeBSD 4.4

   El proceso de ingenieria de releases de FreeBSD 4.4 comenzo formalmente el
   1 de Agosto de 2001. Despues de esa fecha todos los "commits" o
   modificaciones sobre la rama RELENG_4 de FreeBSD tuvieron que ser
   aprobados explicitamente por el Grupo de ingenieria de releases
   <re@FreeBSD.org>. La primera "release candidate" para la arquitectura x86
   aparecio el 16 de Agosto, seguida por otras cuatro releases candidatas
   hasta que vio la luz la release final el 18 de Septiembre. El "security
   officer" estuvo muy involucrado en la ultima semana del proceso ya que se
   descubrieron varios problemas de seguridad en las "release candidates"
   iniciales. Mas de 500 correos electronicos fueron enviados al Grupo de
   ingenieria de releases <re@FreeBSD.org> en poco mas 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 ingenieria de releases.
   Este hecho sera incluso mas importante a medida que FreeBSD vaya estando
   disponible para mas plataformas.

7. Directrices para el futuro

   Es de vital importancia para nuestras actividades de ingenieria de
   releases el ser capaces de crecer al mismo ritmo que nuestra base de
   usuarios. Junto con estas lineas estamos trabajando duramente en los
   procedimientos involucrados en la produccion de releases de FreeBSD.

     * Paralelismo - Algunas partes de la construccion de la release son
       "vergonzosamente paralelas". La mayoria de las tareas que se realizan
       son intensivas en entrada-salida, de tal forma que resulta mas
       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 jerarquias de
       directorios dentro del entorno chroot(2), entonces el "checkout" de
       los arboles de ports y de los doc se puede producir al mismo tiempo
       que la ejecucion en otro disco del comando make world. Mediante la
       utilizacion de un sistema RAID (hardware o software) se puede reducir
       significativamente el tiempo total de construccion 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 Regresion - Se necesitan mejores herramientas automatizadas
       para comprobar la correccion del sistema FreeBSD.

     * Herramientas de Instalacion - Nuestro programa de instalacion ha
       sobrepasado su tiempo de vida previsto. Se encuentran en desarrollo
       varios proyectos para proporcionar un mecanismo de instalacion mas
       avanzado. Uno de los mas prometedores es el proyecto libh[5] cuyo
       objetivo consiste en proporcionar un entorno de paquetes nuevo e
       inteligente junto con un programa de instalacion grafico.

8. Agradecimientos

   Me gustaria agradecer a Jordan Hubbard por darme la oportunidad de
   colaborar en algunas de las responsabilidades del equipo de ingenieria de
   releases en FreeBSD 4.4 y tambien me gustaria agradecer publicamente su
   trabajo y dedicacion durante todos estos anos para poder situar a FreeBSD
   en el sitio de honor que le corresponde hoy dia. Por supuesto que la
   release 4.4 no hubiera visto la luz sin el trabajo de Satoshi Asami, Steve
   Price, Bruce A. Mah, Nik Clayton, David O'Brien, Kris Kennaway, John
   Baldwin y del resto de la comunidad FreeBSD. Tambien me gustaria agradecer
   especialmente a Rodney W. Grimes, Poul-Henning Kamp y muchos otros que
   trabajaron en las herramientas de ingenieria de releases en los comienzos
   del sistema FreeBSD. Este articulo esta basado en documentos de ingenieria
   de releases del CSRG[14], el NetBSD Project[11] y en las notas del proceso
   de ingenieria 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
