diff options
| author | J. Vicente Carrasco <carvay@FreeBSD.org> | 2005-01-12 19:40:40 +0000 |
|---|---|---|
| committer | J. Vicente Carrasco <carvay@FreeBSD.org> | 2005-01-12 19:40:40 +0000 |
| commit | 996780c87fb72c419a5922ad7a09c4f8588f720c (patch) | |
| tree | e09ec3db72b7c808b7ccba821486e9663f191321 /es_ES.ISO8859-1/articles | |
| parent | bb563abcf70bab40636697f7f5befdccffff1383 (diff) | |
| download | doc-996780c87fb72c419a5922ad7a09c4f8588f720c.tar.gz doc-996780c87fb72c419a5922ad7a09c4f8588f720c.zip | |
New translation added.
Submitted by: Juan F. Rodriguez jrh at it.uc3m.es
Approved by: jesusr (mentor)
Notes
Notes:
svn path=/head/; revision=23531
Diffstat (limited to 'es_ES.ISO8859-1/articles')
| -rw-r--r-- | es_ES.ISO8859-1/articles/releng/article.sgml | 1149 |
1 files changed, 1149 insertions, 0 deletions
diff --git a/es_ES.ISO8859-1/articles/releng/article.sgml b/es_ES.ISO8859-1/articles/releng/article.sgml new file mode 100644 index 0000000000..c437fe506c --- /dev/null +++ b/es_ES.ISO8859-1/articles/releng/article.sgml @@ -0,0 +1,1149 @@ +<!-- + The FreeBSD Documentation Project + $FreeBSD$ +--> + +<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ +<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> +%man; +<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous +FreeBSD Entities//EN"> %freebsd; +<!ENTITY % newsgroups PUBLIC "-//FreeBSD//ENTITIES DocBook Newsgroup Entities//ES"> %newsgroups; +<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> +%authors; +<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//ES"> +%mailing-lists; +<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//ES"> +%translators; +<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN"> +%trademarks; +<!ENTITY % teams PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//EN"> +%teams; +<!ENTITY % not.published "IGNORE"> +]> + + +<article> + <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> + + <pubdate>$FreeBSD$</pubdate> + + <legalnotice id="trademarks" role="trademarks"> + &tm-attrib.freebsd; + &tm-attrib.cvsup; + &tm-attrib.intel; + &tm-attrib.xfree86; + &tm-attrib.general; + </legalnotice> + + <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>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> |