diff options
Diffstat (limited to 'es_ES.ISO8859-1/articles/releng/article.sgml')
| -rw-r--r-- | es_ES.ISO8859-1/articles/releng/article.sgml | 1138 |
1 files changed, 0 insertions, 1138 deletions
diff --git a/es_ES.ISO8859-1/articles/releng/article.sgml b/es_ES.ISO8859-1/articles/releng/article.sgml deleted file mode 100644 index b1262b3574..0000000000 --- a/es_ES.ISO8859-1/articles/releng/article.sgml +++ /dev/null @@ -1,1138 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-1" standalone="no"?> -<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN" - "../../../share/sgml/freebsd42.dtd" [ -<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//ES" "../../share/sgml/entities.ent"> -%entities; -]> - -<!-- - The FreeBSD Documentation Project - $FreeBSD$ ---> - -<article lang='es'> - <title>Proceso de generación de releases en FreeBSD</title> - <articleinfo> - - <!-- Este artículo se presentó en la BSDConferece Europea celebrada en Brighton, UK - el 11 de Noviembre de 2001 --> - <confgroup> - <confdates>November 2001</confdates> - <conftitle>BSDCon Europe</conftitle> - </confgroup> - - <authorgroup> - <author> - <firstname>Murray</firstname> - <surname>Stokely</surname> - <authorblurb> - <para> He estado colaborando con el desarrollo de - productos basados en FreeBSD desde 1997 en Walnut Creek - CDROM, BSDi, y actualmente en Wind River Systems. FreeBSD - 4.4 ha sido la primera release en la que he tenido el - placer de participar.</para> - </authorblurb> <affiliation> - <address><email>murray@FreeBSD.org</email> <otheraddr><ulink - url="http://www.FreeBSD.org/~murray/"></ulink></otheraddr> - </address> </affiliation> </author> </authorgroup> - - <legalnotice id="trademarks" role="trademarks"> - &tm-attrib.freebsd; - &tm-attrib.cvsup; - &tm-attrib.intel; - &tm-attrib.xfree86; - &tm-attrib.general; - </legalnotice> - - <pubdate>$FreeBSD$</pubdate> - - <releaseinfo>$FreeBSD$</releaseinfo> - - <abstract> - <para>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.</para> - &trans.es.jrh; - </abstract> - </articleinfo> - -<!-- Introduction --> -<sect1 id="introduction"> - <title>Introducción</title> - - <para>El desarrollo de &os; es un proceso realmente abierto al - público. FreeBSD se alimenta de contribuciones de miles de - personas del mundo entero. El Proyecto &os; proporciona - acceso público a través de <acronym>CVS</acronym>[1] de tal - forma que cualquiera puede acceder a los mensajes de log y a los - archivos de diferencias (también conocidos como <quote>diffs</quote> 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 - <quote>selecto</quote> grupo de en torno a 300 personas que - poseen dicho acceso de escritura - en el repositorio de <acronym>CVS</acronym>. Estos - <emphasis>committers[6]</emphasis> se responsabilizan del - desarrollo del corazón de &os;. Un - <emphasis>core-team[7]</emphasis> compuesto por desarrolladores muy - experimentados proporciona ciertas directrices a la - dirección que va a tomar el proyecto.</para> - - - <para>El rápido ritmo de desarrollo de <systemitem - class="osname">FreeBSD</systemitem> 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 <emphasis>HEAD</emphasis> o - <emphasis>trunk</emphasis> (tronco) y constituye el punto de - desarrollo más avanzado del árbol CVS. Esta rama consituye lo que - llamamos <quote>FreeBSD-CURRENT</quote> o simplemente - <quote>-CURRENT</quote> para abreviar.</para> - - <para>También se mantiene una rama más estable, conocida como - <quote>FreeBSD-STABLE</quote> o <quote>-STABLE</quote>. - Ambas ramas conviven en el repositorio maestro de CVS localizado - en California y dicho repositorio se replica vía - <application class="software">CVSup</application>[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 - <quote>bleeding-edge</quote> en inglés) del desarrollo del sistema - &os; 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.</para> - - <para>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 <systemitem class="resource">ftp://stable.FreeBSD.org/</systemitem>. - La amplia disponibilidad de releases de copias binarias - actualizadas del sistema (<quote>snapshosts</quote>) 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 <quote><command>make</command> - <maketarget>world</maketarget></quote>[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.</para> - - <para>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 <application class="software">GNATS</application>[9] - utilizando el correo eletrónico, la aplicación &man.send-pr.1; o - vía la interfaz web proporcionada en <ulink - url="http://www.FreeBSD.org/send-pr.html"></ulink>. Además de la - multitud de listas de correo de carácter técnico que &os; pone - a nuestra disposición, el &a.qa; proporciona un foro de - discusión sobre aspectos <quote>a pulir</quote> del sistema - antes de su salida.</para> - - <para>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 - <emphasis>RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></emphasis> - actualizadas.</para> - - <para>La <xref linkend="release-proc"/> describe las distintas fases del - proceso de ingeniería de releases que se utiliza para construir el - sistema real mientras que <xref linkend="release-build"/> describe - el proceso de contrucción en sí mismo. <xref - linkend="extensibility"/> describe cómo la release base puede ser - ampliada por terceras partes y <xref linkend="lessons-learned"/> - detalla algunas de las lecciones aprendidas durante la generación - de la release FreeBSD 4.4. Por último, <xref linkend="future"/> - presenta caminos futuros de desarrollo.</para> </sect1> - -<!-- Release Process --> -<sect1 id="release-proc"> - <title>Proceso de ingeniería de releases</title> - - <para>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 - <quote>barrido MFC</quote>. <acronym>MFC</acronym> - significa en inglés <quote>Merge From CURRENT</quote> (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.</para> - - <sect2> - <title>Revisión de Código</title> - - <para>Treinta días antes del lanzamiento de una release dada - el repositorio de código fuente entra en una fase de <quote>code - slush</quote> (<quote>código aguanieve</quote>, 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 &a.re;. Los cambios permitidos - en esta fase de 15 días de duración son los siguientes:</para> - - <itemizedlist> - <listitem> - <para>Arreglo de bugs o errores.</para> - </listitem> - - <listitem> - <para>Actualizaciones de la documentación.</para> - </listitem> - - <listitem> - <para>Parches relacionados con cualquier tipo de fallo en la - seguridad.</para> - </listitem> - - <listitem> - <para>Cambios pequeños en controladores de dispositivos, tales - como la adición de identificadores de dispositivo.</para> - </listitem> - - <listitem> - <para>Cualquier cambio adicional que el equipo de ingeniería - de releases considere justificado, teniendo siempre en - cuenta el riesgo potencial que puede conllevar.</para> - </listitem> - </itemizedlist> - - <para>Después de los primeros 15 días de código - <quote>slush</quote>, se genera una <emphasis>release - candidate</emphasis> (candidata a release) o <quote>RC</quote> - para su testeo exhaustivo - por parte de la comunidad de usuarios y el código fuente entra - en la fase de <quote>code freeze</quote> 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, el equipo de ingeniería - de releases se comunica constantemente con el equipo del - <quote>security officer</quote>, los equipos encargados de - mantener la documentación 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.</para> - </sect2> - - <sect2> - <title>Lista de tareas para la release final.</title> - - <para>Cuando todos los problemas encontrados en las releases - candidatas se han corregido, se puede comenzar con el - procedimiento de <quote>pulimiento o enbellecimiento</quote> de - la release final.</para> - - <sect3> - <title>Creación de una Rama Release</title> - - <para>Como se describe en la introducción, la rama - <literal>RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></literal> - es una característica relativamente nueva de nuestra - metodología de generación de releases. El primer paso - para crear esta rama consiste en asegurar que el código fuente - utilizado <quote>proviene</quote> de la versión más reciente de - <literal>RELENG_<replaceable>X</replaceable></literal>.</para> - - <screen>/usr/src&prompt.root; <userinput>cvs update -rRELENG_4 -P -d</userinput></screen> - - <para>El siguiente paso consiste en crear una etiqueta de rama, - (<emphasis>tag</emphasis>), de esta forma se pueden generar - diferencias entre el código actual y la rama de inicio - fácilmente, utilizando CVS:</para> - - <screen>/usr/src&prompt.root; <userinput>cvs rtag -rRELENG_4 RELENG_4_8_BP src</userinput></screen> - - <para>Y a continuación se crea la etiqueta de la rama:</para> - - <screen>/usr/src&prompt.root; <userinput>cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src</userinput></screen> - - <note> - <para><emphasis>Las etiquetas - <literal>RELENG_<replaceable>*</replaceable></literal> - sólo pueden ser utilizadas por los CVS-meisters y los - ingenieros de releases.</emphasis> - </para> - </note> - - <sidebar> - <para>Una <quote><emphasis>etiqueta o tag</emphasis></quote> es una - característica de CVS que sirve para identificar el código - fuente en un determinado instante del tiempo. Mediante el etiquetado del - árbol, nos aseguramos de que las futuras - releases puedan generar diferencias con respecto al mismo - código fuente que se utilizó para generar las releases - oficiales anteriores.</para> </sidebar> - - <mediaobject> - <imageobject> - <imagedata fileref="branches-head" align="center"/> - </imageobject> - - <textobject> - <phrase>Rama FreeBSD Development (Rama de Desarrollo)</phrase> - </textobject> - </mediaobject> - - <mediaobject> - <imageobject> - <imagedata fileref="branches-releng3" align="center"/> - </imageobject> - - <textobject> - <phrase>Rama FreeBSD 3.x STABLE</phrase> - </textobject> - </mediaobject> - - <mediaobject> - <imageobject> - <imagedata fileref="branches-releng4" align="center"/> - </imageobject> - - <textobject> - <phrase>Rama FreeBSD 4.x STABLE</phrase> - </textobject> - </mediaobject> - - </sect3> - - <sect3 id="versionbump"> - <title>Elevación del número de versión</title> - - <para>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 número de - versión correcto:</para> - - <itemizedlist> - <listitem> - <para><filename>doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml - </filename></para> - </listitem> - - <listitem> - <para><filename>doc/en_US.ISO8859-1/books/porters-handbook/book.sgml - </filename></para> - </listitem> - - <listitem> - <para><filename>doc/share/sgml/freebsd.ent</filename></para> - </listitem> - - <listitem> - <para><filename>src/Makefile.inc1</filename></para> - </listitem> - - <listitem> - <para><filename>src/UPDATING</filename></para> - </listitem> - - <listitem> - <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</filename></para> - </listitem> - - <listitem> - <para><filename>src/release/Makefile</filename></para> - </listitem> - - <listitem> - <para><filename>src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl</filename></para> - </listitem> - - <listitem> - <para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para> - </listitem> - - <listitem> - <para><filename>src/release/doc/share/sgml/release.ent</filename></para> - </listitem> - - <listitem> - <para><filename>src/share/examples/cvsup/standard-supfile</filename></para> - </listitem> - - <listitem> - <para><filename>src/sys/conf/newvers.sh</filename></para> - </listitem> - - <listitem> - <para><filename>src/sys/sys/param.h</filename></para> - </listitem> - - <listitem> - <para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/docs.sgml</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/cgi/ports.cgi</filename></para> - </listitem> - - <listitem> - <para><filename>ports/Tools/scripts/release/config</filename></para> - </listitem> - - </itemizedlist> - - <para>El fichero <quote>release notes</quote> y el fichero - <quote>errata</quote> también deben ajustarse de acuerdo con - la nueva release (en la rama de la release) y deben cortarse - adecuadamente en las ramas stable/currrent):</para> - - <itemizedlist> - <listitem> - <para><filename>src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml - </filename></para> - </listitem> - - <listitem> - <para><filename>src/release/doc/en_US.ISO8859-1/errata/article.sgml - </filename></para> - </listitem> - </itemizedlist> - - <para><application>Sysinstall</application> debe actualizarse - para que proporcione el número actual de ports disponibles y - la cantidad de espacio de disco requerida para instalar dicha - colección de ports. Esta información se encuentra almacenada - actualmente en el fichero - <filename>src/release/sysinstall/dist.c</filename>. </para> - - <para>Después de construir la release se debe actualizar el - número almacenado en los siguientes ficheros para anunciar la - release al resto del mundo:</para> - - <itemizedlist> - <listitem> - <para><filename>www/share/sgml/includes.release.sgml</filename></para> - </listitem> - - <listitem> - <para><filename>www/share/sgml/includes.release.xsl</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/releases/*</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/releng/index.sgml</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/news/news.xml</filename></para> - </listitem> - - <listitem> - <para><filename>www/en/search/web.atoz</filename></para> - </listitem> - - <listitem> - <para><filename>src/share/misc/bsd-family-tree</filename></para> - </listitem> - - </itemizedlist> - - </sect3> - - <sect3> - <title>Creación de las etiquetas de release</title> - - <para>Cuando la release final se encuentra preparada se utiliza - el siguiente comando para crear la etiqueta (a modo de - ejemplo) <literal>RELENG_4_8_0_RELEASE</literal>.</para> - - <screen>/usr/src&prompt.root; <userinput>cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src</userinput></screen> - - <para>Los gestores de los proyectos de Documentación y de los - Ports se responsabilizan del correcto etiquetado de sus - respectivos árboles utilizando - <literal>RELEASE_4_8_0</literal>. </para> - - <para>Ocasionalmente se puede presentar un apaño o arreglo de - última hora justo <emphasis>después</emphasis> de la creación - de las etiquetas finales. En la práctica esto no constituye un - problema ya que <acronym>CVS</acronym> permite cierta - manipulación de etiquetados mediante <command>cvs tag -d - <replaceable>nombredeetiqueta nombredefichero</replaceable> </command>. Es - muy importante que dichos cambios de última hora se etiqueten - adecuadamente para que pasen a formar parte de la nueva - release. Las releases de &os; deben ser siempre - <quote>reproducibles</quote>. Los <quote>hacks</quote> - locales dentro del entorno de ingeniería de releases no están - permitidos salvo que se efectúen mediante una correcta - manipulación y notificación.</para> - </sect3> </sect2> </sect1> - -<!-- Release Building --> -<sect1 id="release-build"> - <title>Construcción de la Release</title> - - <para>Cualquier persona dueña de una potente máquina y con acceso de lectura - al repositorio de código fuente puede <quote>construir</quote> las - <quote>releases</quote> de &os;. En la práctica esto significa - que cualquiera puede generar el proceso de construcción de - releases, ya que, como se comentó con anterioridad, &os; 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 &man.vn.4;. (En -CURRENT, - este dispositivo ha sido reemplazado por el nuevo driver de discos - en memoria denominado &man.md.4;.) Si el dispositivo no se - encuentra cargado en el kernel, debería cargarse automáticamente - al ejecutar el comando &man.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 - <filename>src/release</filename>. Estas herramientas proporcionan - una forma consistente y robusta de construir releases de &os;. - Una release completa se puede construir utilizando un único - comando, incluyendo la creación de las imágenes - <acronym>ISO</acronym> 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 <command>make release</command>.</para> - - <sect2> - <title><command>make release</command></title> - - <para>Para poder construir la releases de una forma exitosa - se debe rellenar primero el directorio - <filename>/usr/obj</filename> ejecutando el comando - <command>make world</command> o simplemente <command>make - buildworld</command>. El target release que utiliza el comando - make necesita varias variables, tal como se muestra a - continuación:</para> - - <itemizedlist> - <listitem> - <para><makevar>CHROOTDIR</makevar> - El directorio que se utiliza para - el entorno de chroot durante la construcción de la release - entera.</para> - </listitem> - - <listitem> - <para><makevar>BUILDNAME</makevar> - El nombre de la release que se va a - construir.</para> - </listitem> - - <listitem> - <para><makevar>CVSROOT</makevar> - La ubicación del repositorio de CVS. - </para> - </listitem> - - <listitem> - <para><makevar>RELEASETAG</makevar> - La etiqueta CVS correspondiente con la - release que se quiere construir.</para> - </listitem> - </itemizedlist> - - <para>Si no se dispone de acceso a un repositorio de CVS local, - se puede realizar una copia espejo (un mirror) con - <ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/synching.html#CVSUP">CVSup</ulink>. - El fichero - <filename>/usr/share/examples/cvsup/cvs-supfile</filename>, - sirve como buen punto de partida para realizar un mirror del - repositorio de CVS.</para> - - <para>Si se omite <makevar>RELEASETAG</makevar>, la release se - construirá a partir de la rama <literal>HEAD</literal> (también - conocida como -CURRENT). Las releases que se construyen desde - el principio se conocen normalmente con el nombre de - <quote>-CURRENT snapshots</quote>.</para> - - <para>Existen otras variables que se pueden editar para adaptar - el proceso de construcción de la release. La mayoría de estas - variables se encuentran documentadas al comienzo de - <filename>src/release/Makefile</filename>. El comando exacto - para contruir la release oficial de FreeBSD 4.7 (x86) - fue:</para> - - <screen><command>make <literal>release CHROOTDIR=/local3/release \ - BUILDNAME=4.7-RELEASE \ - CVSROOT=/host/cvs/usr/home/ncvs \ - RELEASETAG=RELENG_4_7_0_RELEASE</literal> - </command> - </screen> - - <para>El <filename>Makefile</filename> de la release se puede - dividir en varios pasos distintos.</para> - - <itemizedlist> - <listitem> - <para>Creación de un entorno de sistema limpio en una - jerarquía de directorios separada utilizando - <quote><command>make <literal>installworld</literal></command></quote>. - </para> - </listitem> - - <listitem> - <para>Comprobación de la correcta versión de los ficheros fuentes - almacenados - en la jerarquía de directorios recién creada, junto con el - chequeo de la documentación y de los ports utilizando, todo - ello a través de CVS.</para> - </listitem> - - <listitem> - <para>Relleno de los directorios <filename>/etc</filename> y - <filename>/dev</filename> dentro del entorno chroot.</para> - </listitem> - - <listitem> - <para>Creación de un <quote>chroot</quote> dentro de la jerarquía de - directorios - creada, para que resulte más dificil que el entorno de la - máquina se vea contaminado por la construcción de la - release.</para> - </listitem> - - <listitem> - <para><command>make world</command> - dentro del entorno de chroot.</para> - </listitem> - - <listitem> - <para>Contrucción de los binarios relacionados con Kerberos.</para> - </listitem> - - <listitem> - <para>Construcción del kernel <filename>GENERIC</filename>.</para> - </listitem> - - <listitem> - <para>Creación de un esqueleto del árbol de directorios donde - se construirán y empaquetarán las distribuciones - binarias.</para> - </listitem> - - <listitem> - <para>Construcción e instalación del conjunto de herramientas de - documentación necesarias para convertir los fuentes de la - documentación (SGML) en los documentos HTML y de texto que pasarán - a formar parte de la release.</para> - </listitem> - - <listitem> - <para>Construcción e instalación de la documentación real - (manuales de usuario, tutoriales, release notes, listas de - compatibilidad de hardware, etc.)</para> - </listitem> - - <listitem> - <para>Construcción de los <quote>decisivos</quote> binarios utilizados - en los disquetes de instalación.</para> - </listitem> - - <listitem> - <para>Colocación adecuada de los de los paquetes de distribución de - binarios y de fuentes.</para> - </listitem> - - <listitem> - <para>Creación del medio de arranque y del disquete <quote>fixit</quote> - o salvamento.</para> - </listitem> - - <listitem> - <para>Creación de la jerarquía de directorios de instalación por FTP.</para> - </listitem> - - <listitem> - <para><emphasis></emphasis> Creación de imágenes ISO para - CDROM/DVD(opcional).</para> - </listitem> - </itemizedlist> - - <para>Para más información sobre la infraestructura involucrada en - el proceso de construcción de la release, el lector puede - consultar &man.release.7;.</para> - - </sect2> - - <sect2> - <title>Construcción de<application>&xfree86;</application></title> - - <para><application>&xfree86;</application> es un componente importante para muchos - usuarios de entornos gráficos. Antes de la release &os; 4.6 las - se usaba &xfree86;3.<replaceable>X</replaceable> por defecto. La forma - más sencilla de construir estas versiones consiste en utilizar - el script <filename>src/release/scripts/X11/build_x.sh</filename>. - Este script requiere que &xfree86; y Tcl/Tk se encuentren - instalados previamente en la máquina donde se realiza la - construcción. Después de compilar los servidores X necesarios, - el script empaqueta todos los ficheros en - <quote>tarballs</quote> que &man.sysinstall.8; sabe cómo - localizar utilizando el directorio <filename>XF86336</filename> - del medio de instalación.</para> - - <para>A partir de FreeBSD 4.6, &man.sysinstall.8; instala - &xfree86; 4.<replaceable>X</replaceable> por defecto, como - cualquier otro conjunto de paquetes. Estos paquetes se pueden - construir a partir del <quote>package-building cluster</quote> - o a partir de las etiquetas del árbol de ports adecuadas.</para> - - <note><para>Es importante borrar cualquier configuración - particular almacenada en <filename>/etc/make.conf</filename>. - Por ejemplo, no sería una idea muy inteligente distribuir binarios que se - construyeron en un sistema con la variable - <varname>CPUTYPE</varname> asignada a un determinado - procesador.</para></note> </sect2> - - <sect2> - <title>Software Contribuido (<quote>ports</quote>)</title> - - <para>La colección de <ulink url="http://www.FreeBSD.org/ports">FreeBSD Ports - </ulink> está compuesta por más de &os.numports; paquetes - de software de terceras partes que se encuentran disponibles para - &os;. El &a.portmgr; se responsabiliza de mantener un árbol - de ports consistente que se pueda utilizar para crear paquetes - binarios, los cuales se añaden a las releases oficiales de - FreeBSD.</para> - - <para>Las actividades de ingeniería de releases para nuestra - colección de paquetes software de terceras partes se encuentra - más allá del objetivo de este documento. Otro artículo, - <ulink - url="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/"></ulink>, - cubre este tema en profundidad.</para> - - </sect2> - - <sect2> - <title>ISOs de la release</title> - - <para>A partir de FreeBSD 4.4, el Proyecto FreeBSD decidió lanzar - gratuitamente al público las cuatro imágenes ISO que - anteriormente se vendían en <emphasis>BSDi/Wind River - Systems/FreeBSD Mall</emphasis> como distribuciones en CDROM - <quote>oficiales</quote>. Cada uno de los cuatro discos debe - contener un <filename>README.TXT</filename> que explica - el contenido de cada disco, un - <filename>CDROM.INF</filename> que proporciona metadatos para - que &man.sysinstall.8; pueda validar la información en él - contenida y un <filename>filename.txt</filename> que - proporciona un <quote>manifiesto</quote>. Este - <emphasis>manifiesto</emphasis> se puede crear utilizando un - simple comando:</para> - - <screen>/stage/cdrom&prompt.root; <userinput>find . -type f | sed -e 's/^\.\///' | sort > filename.txt</userinput></screen> - - <para>Los requisitos concretos de cada CD se resumen a continuación.</para> - - <sect3> - <title>Disco 1</title> - - <para>El primer disco se crea casi en su totalidad a partir del - comando <command>make release</command>. Los únicos cambios - que se deben realizar dentro del directorio - <filename>disc1</filename> son la adición de un directorio - <filename>tools</filename>, de <application - class="software">&xfree86;</application> y de los paquetes de - terceras partes más populares que quepan dentro del espacio - remanente de dicho primer disco. El directorio - <filename>tools</filename> contiene el software que permite a - los usuarios crear disquetes de instalación 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 - característica de autoarranque desde CD.</para> - - <para>Si se proporciona una versión alternativa de &xfree86;, - &man.sysinstall.8; debe actualizarse para reflejar la nueva - localización y las instrucciones de instalación. El código - relevante se encuentra en - <filename>src/release/sysinstall</filename> en -STABLE o en - <filename>src/usr.sbin/sysinstall</filename> en -CURRENT. - Específicamente, se deben actualizar - <filename>dist.c</filename>, <filename>menus.c</filename> y - <filename>config.c</filename>.</para> </sect3> - - <sect3> - <title>Disco 2</title> - - <para>El segundo disco se crea en su mayor parte a partir del - comando <command>make release</command>. Este disco contiene - un <quote>sistema de ficheros vivo</quote>, que se puede - utilizar a partir de &man.sysinstall.8; para resolver - problemas durante el proceso de instalación de &os;. Este - disco se debe construir como autoarrancable y debe contener - una copia comprimida del repositorio de CVS dentro del - directorio <filename>CVSROOT</filename>, junto con - demostraciones de software comercial localizadas dentro del - directorio <filename>commerce</filename>.</para> </sect3> - - <sect3> - <title>Discos 3 and 4</title> - - <para>Los dos discos que quedan contienen paquetes de software - para &os;. Estos paquetes deben agruparse de - tal forma que un paquete y todas sus - <emphasis>dependencias</emphasis> quepan en el mismo disco. - Se puede obtener más información sobre la creación de estos - discos en el artículo <ulink - url="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/"></ulink> - .</para> </sect3> </sect2> - </sect1> - -<!-- Distribution --> -<sect1 id="distribution"> - <title>Distribución</title> - - <sect2 id="dist-ftp"> - <title>Servidores de FTP</title> - - <para>Cuando se ha probado exhaustivamente la release y se ha - empaquetado debidamente para proceder a su distribución, se debe - actualizar el sitio maestro de FTP. Los sitios FTP oficiales de - FreeBSD son mirrors del sitio FTP maestro, también llamado - <hostid>ftp-master</hostid>. Cuando la release está lista, se - deben modificar los siguientes ficheros en el servidor - <hostid>ftp-master</hostid>:</para> - - <variablelist> - <varlistentry> - <term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/</filename></term> - <listitem> - <para>El directorio de instalación dde FTP que se crea con - la salida del comando <command>make release</command>.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><filename>/pub/FreeBSD/ports/<replaceable>arch</replaceable>/packages-<replaceable>X.Y</replaceable>-release/</filename></term> - <listitem><para>La construcción del paquete completo de la - release.</para></listitem> - </varlistentry> - - <varlistentry> - <term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/tools</filename></term> - <listitem><para>Un enlace simbólico a - <filename>../../../tools</filename>.</para></listitem> - </varlistentry> - - <varlistentry> - <term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/packages</filename></term> - <listitem><para>Un enlace simbólico a - <filename>../../../ports/<replaceable>arch</replaceable>/packages-<replaceable>X.Y</replaceable>-release</filename>.</para></listitem> - </varlistentry> - - <varlistentry> - <term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/ISO-IMAGES/<replaceable>X.Y</replaceable>/<replaceable>X.Y</replaceable>-RELEASE-<replaceable>arch</replaceable>-*.iso</filename></term> - <listitem><para>Las imágenes ISO. El <quote>*</quote> se - sustituye por <filename>disc1</filename>, <filename>disc2</filename>, etc. - Solo si existe <filename>disc1</filename> junto con un CD de - primera instalación alternativo (por ejemplo una instalación - recortada o reducida sin sistema de ventanas) puede existir - también un <filename>mini</filename>.</para> - </listitem> - </varlistentry> - </variablelist> - - <para>Para obtener más información sobre la arquitectura de mirrors - para la distribución del sistema FreeBSD, se ruega al lector que - consulte el artículo <ulink url="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/">Mirroring - FreeBSD</ulink>.</para> - - <para>Puede que transcurran desde varias horas hasta varios días - hasta que la mayoría de los sitios FTP Tier-1 se actualicen con - respecto al <hostid>ftp-master</hostid>, esto depende de si un - determinado paquete se cargó o no se cargó en determinado - instante. Es imperativo que los ingenieros de releases se - coordinen con &a.mirror-announce; antes de anunciar la - disponibilidad general del nuevo software en los sitios FTP. - Para que todo fuera bien el paquete de la release se debería cargar al menos - cuatro días antes del día oficial de lanzamiento de la release. - Los permisos para el grupo <quote>other</quote> deben desactivarse - completamente para que los sitios espejos puedan descargar la - release pero no así los usuarios finales, hasta que llegue el día - oficial del lanzamiento. Se debe enviar un correo a - &a.mirror-announce; 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 público en general. Se - debe comprobar que se incluye información relativa a zonas - horarias, por ejemplo información relativa a GMT.</para> </sect2> - - <sect2 id="dist-cdrom"> - <title>Replicación de CD-ROMs</title> - - <para>Dentro de poco tiempo: Consejos para enviar ISOs de FreeBSD - a un replicador e información sobre las medidas de - aseguramiento de la calidad que se deben tomar.</para> - </sect2> - -</sect1> - -<!-- Extensibility --> -<sect1 id="extensibility"> - <title>Extensibilidad</title> - - <para>Aunque &os; consitituye un sistema operativo - <quote>completo</quote>, no existe nada que nos obligue a - utilizarlo exactamente igual que como se ha empaquetado para crear - la distribución. Es decir, el sistema &os; 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 <quote>regla</quote> sobre este tema es que - si se piensa distribuir &os; con una serie de cambios profundos en - él , se anima a que se <emphasis>documenten - adecuadamente dichos mejoras</emphasis>. La comunidad &os; 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.</para> - - <sect2> - <title>Creación de disquetes de arranque a medida</title> - - <para>Muchas organizaciones poseen complejos requisitos que pueden - consistir en módulos del kernel adicionales o herramientas de - entorno de usuario que deben añadirse en los discos de - instalación. La forma <quote>rápida y sucia</quote> de añadir - estas cosas consiste en modificar el directorio temporal que - contiene la estructura de un <command>make - release</command>:</para> - - - <itemizedlist> - <listitem> - <para>Aplicar parches o añadir archivos adicionales dentro del - directorio chroot de construcción de la release.</para> - </listitem> - - <listitem> - <para><command>rm - ${CHROOTDIR}/usr/obj/usr/src/release/release.[59]</command></para> - </listitem> - - <listitem> - <para>Reconstruir &man.sysinstall.8;, el kernel o cualquier - otra parte del sistema que se vea afectada por los - cambios.</para> - </listitem> - - <listitem> - <para><command>chroot ${CHROOTDIR} ./mk floppies - </command></para> - </listitem> - - </itemizedlist> - - <para>Los nuevos disquetes de instalación estarán en - <filename>${CHROOTDIR}/R/stage/floppies</filename>.</para> - - <para>También se puede llamar el objetivo de make - <filename>boot.flp</filename> o directamente al <quote>script</quote> de - creación del - sistema de ficheros <filename>src/release/scripts/doFS.sh</filename>.</para> - - <para>Los parches locales también se pueden proporcionar al - proceso de construcción de la release mediante la definición de - la variable <makevar>LOCAL_PATCH</makevar> dentro de - <command>make release</command>. </para> </sect2> - - <sect2> - <title><quote>Scripts</quote> para <command>sysinstall</command></title> - - <para>La instalación y configuración del sistema &os; a través - de &man.sysinstall.8; se puede modificar mediante - <quote>scripts</quote> para que proporcione instalaciones - automáticas a grandes organizaciones. Esta funcionalidad se - puede utilizar conjuntamente con &intel; PXE[13] para arrancar - sistemas a través de la red, o a través de disquetes de arranque - a medida utilizando un <quote>script</quote> de sysinstall. Un - ejemplo de guión sysinstall se encuentra disponible en - <filename>src/release/sysinstall/install.cfg</filename>. - </para> - </sect2> -</sect1> - -<!-- Lessons Learned --> -<sect1 id="lessons-learned"> - <title>Lecciones aprendidas a partir de FreeBSD 4.4</title> - - <para>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 <quote>commits</quote> o modificaciones sobre la rama - <literal>RELENG_4</literal> de FreeBSD tuvieron que ser aprobados - explícitamente por el &a.re;. La primera <quote>release - candidate</quote> 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 <quote>security - officer</quote> estuvo muy involucrado en la última semana del - proceso ya que se descubrieron varios problemas de seguridad en - las <quote>release candidates</quote> iniciales. Más - de <emphasis>500</emphasis> correos electrónicos fueron enviados al - &a.re; en poco más de un mes.</para> - - <para>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 &os; 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 &os; vaya estando - disponible para más plataformas.</para> - </sect1> - -<!-- Future Directions --> -<sect1 id="future"> - <title>Directrices para el futuro</title> - - <para>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.</para> - - <itemizedlist> - <listitem> - <para><emphasis>Paralelismo</emphasis> - Algunas partes de la - construcción de la release son <quote>vergonzosamente - paralelas</quote>. 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 <command>make release</command>. Si se utilizan - varios discos para las distintas jerarquías de directorios - dentro del entorno &man.chroot.2;, entonces el - <quote>checkout</quote> de los árboles de - <filename>ports</filename> y de los <filename>doc</filename> - se puede producir al mismo tiempo que la ejecución en otro - disco del comando <command>make world</command>. Mediante la - utilización de un sistema <acronym>RAID</acronym> (hardware o - software) se puede reducir significativamente el tiempo - total de construcción de la release.</para> </listitem> - - <listitem> - <para><emphasis>Releases construidas para otros sistemas finales - (<quote>cross building</quote>)</emphasis> : - ?Se puede construir una release - para IA-64 o Alpha en un hardware x86? <command>make - TARGET=ia64 release</command>. </para> </listitem> - - <listitem> - <para><emphasis>Tests de Regresión</emphasis> - Se necesitan - mejores herramientas automatizadas para comprobar la - corrección del sistema &os;.</para> </listitem> - - <listitem> - <para><emphasis>Herramientas de Instalación</emphasis> - 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.</para> </listitem> - </itemizedlist> - -</sect1> - -<!-- Acknowledgements --> -<sect1 id="ackno"> -<title>Agradecimientos</title> - - <para>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 &os; 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 &a.asami;, &a.steve;, - &a.bmah;, &a.nik;, &a.obrien;, &a.kris;, &a.jhb; y del resto de la - comunidad &os;. También me gustaría agradecer especialmente a - &a.rgrimes;, &a.phk; y muchos otros que trabajaron en las - herramientas de ingeniería de releases en los comienzos del - sistema &os;. 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].</para> </sect1> - -<!-- Reference / Biblio Section --> -<sect1 id="biblio"> - <title>Lecturas recomendadas</title> - <para>[1] CVS - Concurrent Versions System - <ulink url="http://www.cvshome.org"></ulink></para> - - <para>[2] CVSup - The CVS-Optimized General Purpose Network File Distribution - System <ulink url="http://www.polstra.com/projects/freeware/CVSup"></ulink> - </para> - - <para>[3] <ulink url="http://bento.FreeBSD.org"></ulink></para> - - <para>[4] FreeBSD Ports Collection - <ulink url="http://www.FreeBSD.org/ports"></ulink></para> - - <para>[5] The libh Project - <ulink url="http://www.FreeBSD.org/projects/libh.html"></ulink></para> - - <para>[6] FreeBSD Committers <ulink - url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html"></ulink> - </para> - - <para>[7] FreeBSD Core-Team - <ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-core.html"></ulink></para> - - <para>[8] FreeBSD Handbook - <ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook"></ulink> - </para> - - <para>[9] GNATS: The GNU Bug Tracking System - <ulink url="http://www.gnu.org/software/gnats"></ulink> - </para> - - <para>[10] FreeBSD PR Statistics - <ulink url="http://www.FreeBSD.org/prstats/index.html"></ulink></para> - - <para>[11] NetBSD Developer Documentation: Release Engineering - <ulink url="http://www.NetBSD.org/developers/releng/index.html"></ulink> - </para> - - <para>[12] John Baldwin's FreeBSD Release Engineering Proposal - <ulink url="http://people.FreeBSD.org/~jhb/docs/releng.txt"></ulink> - </para> - - <para>[13] PXE Jumpstart Guide - <ulink - url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html"></ulink> - </para> - - <para>[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: - <ulink url="http://docs.FreeBSD.org/44doc/papers/releng.html"> -<emphasis>The Release Engineering of 4.3BSD</emphasis></ulink> - </para> -</sect1> -</article> |