              Proceso de generacion de releases en FreeBSD

  Murray Stokely

   <murray@FreeBSD.org> 
    

   $FreeBSD: doc/es_ES.ISO8859-1/articles/releng/article.sgml,v 1.3
   2007/11/08 21:49:11 carvay Exp $

   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.

   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>.

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

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 Section 2 describe las distintas fases del proceso de
   ingenieria de releases que se utiliza para construir el sistema
   real mientras que Section 3 describe el proceso de contruccion en
   si mismo. Section 5 describe como la release base puede ser
   ampliada por terceras partes y Section 6 detalla algunas de las
   lecciones aprendidas durante la generacion de la release FreeBSD
   4.4. Por ultimo, Section 7 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

     Note: 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.sgml

     * doc/en_US.ISO8859-1/books/porters-handbook/book.sgml

     * doc/share/sgml/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/sgml/release.dsl

     * src/release/doc/share/examples/Makefile.relnotesng

     * src/release/doc/share/sgml/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.sgml

     * 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.sgml

     * src/release/doc/en_US.ISO8859-1/errata/article.sgml

   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/sgml/includes.release.sgml

     * www/share/sgml/includes.release.xsl

     * www/en/releases/*

     * www/en/releng/index.sgml

     * 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
   XFree863.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 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 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.

     Note: 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 20,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
   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,
   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 <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. Tambien me gustaria agradecer
   especialmente a Rodney Grimes <rgrimes@FreeBSD.org>, Poul-Henning
   Kamp <phk@FreeBSD.org> 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

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

          Puede descargar este y muchos otros documentos desde
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentacion antes de escribir
                  a la lista <questions@FreeBSD.org>.
    Envie sus preguntas sobre la documentacion a <doc@FreeBSD.org>.
