1120 lines
47 KiB
XML
1120 lines
47 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
$FreeBSD$
|
|
-->
|
|
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="es">
|
|
|
|
<info><title>Proceso de generación de releases en FreeBSD</title>
|
|
|
|
|
|
<confgroup>
|
|
<confdates>November 2001</confdates>
|
|
<conftitle>BSDCon Europe</conftitle>
|
|
</confgroup>
|
|
|
|
<authorgroup>
|
|
<author><personname><firstname>Murray</firstname><surname>Stokely</surname></personname><personblurb>
|
|
<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>
|
|
</personblurb><affiliation>
|
|
<address><email>murray@FreeBSD.org</email> <otheraddr xlink:href="http://www.FreeBSD.org/~murray/">http://www.FreeBSD.org/~murray/</otheraddr>
|
|
</address> </affiliation></author> </authorgroup>
|
|
|
|
<legalnotice xml: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>
|
|
</info>
|
|
|
|
<!-- Introduction -->
|
|
<sect1 xml: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>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>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>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>
|
|
<buildtarget>world</buildtarget></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>GNATS</application>[9]
|
|
utilizando el correo eletrónico, la aplicación &man.send-pr.1; o
|
|
vía la interfaz web proporcionada en <uri xlink:href="http://www.FreeBSD.org/send-pr.html">http://www.FreeBSD.org/send-pr.html</uri>. 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 xml: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_X_Y</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_X</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_*</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 xml: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.xml
|
|
</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>doc/en_US.ISO8859-1/books/porters-handbook/book.xml
|
|
</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>doc/share/xml/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/xml/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/xml/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.xml</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.xml
|
|
</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>src/release/doc/en_US.ISO8859-1/errata/article.xml
|
|
</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/xml/includes.release.xml</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>www/share/xml/includes.release.xsl</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>www/en/releases/*</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>www/en/releng/index.xml</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
|
|
nombredeetiqueta nombredefichero </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 xml: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><varname>CHROOTDIR</varname> - El directorio que se utiliza para
|
|
el entorno de chroot durante la construcción de la release
|
|
entera.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>BUILDNAME</varname> - El nombre de la release que se va a
|
|
construir.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>CVSROOT</varname> - La ubicación del repositorio de CVS.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><varname>RELEASETAG</varname> - 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
|
|
<link xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/synching.html#CVSUP">CVSup</link>.
|
|
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 <varname>RELEASETAG</varname>, 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 release CHROOTDIR=/local3/release \
|
|
BUILDNAME=4.7-RELEASE \
|
|
CVSROOT=/host/cvs/usr/home/ncvs \
|
|
RELEASETAG=RELENG_4_7_0_RELEASE
|
|
</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 installworld</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/> 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 <link xlink:href="http://www.FreeBSD.org/ports">FreeBSD Ports
|
|
</link> 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,
|
|
<uri xlink:href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/">http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/</uri>,
|
|
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>&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 <uri xlink:href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/">http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/</uri>
|
|
.</para> </sect3> </sect2>
|
|
</sect1>
|
|
|
|
<!-- Distribution -->
|
|
<sect1 xml:id="distribution">
|
|
<title>Distribución</title>
|
|
|
|
<sect2 xml: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
|
|
<systemitem>ftp-master</systemitem>. Cuando la release está lista, se
|
|
deben modificar los siguientes ficheros en el servidor
|
|
<systemitem>ftp-master</systemitem>:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><filename>/pub/FreeBSD/releases/arch/X.Y-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/arch/packages-X.Y-release/</filename></term>
|
|
<listitem><para>La construcción del paquete completo de la
|
|
release.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><filename>/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools</filename></term>
|
|
<listitem><para>Un enlace simbólico a
|
|
<filename>../../../tools</filename>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><filename>/pub/FreeBSD/releases/arch/X.Y-RELEASE/packages</filename></term>
|
|
<listitem><para>Un enlace simbólico a
|
|
<filename>../../../ports/arch/packages-X.Y-release</filename>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><filename>/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.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 <link xlink:href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/">Mirroring
|
|
FreeBSD</link>.</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 <systemitem>ftp-master</systemitem>, 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 xml: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 xml: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 <varname>LOCAL_PATCH</varname> 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 xml: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 xml: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 xml: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 xml:id="biblio">
|
|
<title>Lecturas recomendadas</title>
|
|
<para>[1] CVS - Concurrent Versions System
|
|
<uri xlink:href="http://www.cvshome.org">http://www.cvshome.org</uri></para>
|
|
|
|
<para>[2] CVSup - The CVS-Optimized General Purpose Network File Distribution
|
|
System <uri xlink:href="http://www.polstra.com/projects/freeware/CVSup">http://www.polstra.com/projects/freeware/CVSup</uri>
|
|
</para>
|
|
|
|
<para>[3] <uri xlink:href="http://bento.FreeBSD.org">http://bento.FreeBSD.org</uri></para>
|
|
|
|
<para>[4] FreeBSD Ports Collection
|
|
<uri xlink:href="http://www.FreeBSD.org/ports">http://www.FreeBSD.org/ports</uri></para>
|
|
|
|
<para>[5] The libh Project
|
|
<uri xlink:href="http://www.FreeBSD.org/projects/libh.html">http://www.FreeBSD.org/projects/libh.html</uri></para>
|
|
|
|
<para>[6] FreeBSD Committers <uri xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html">http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html</uri>
|
|
</para>
|
|
|
|
<para>[7] FreeBSD Core-Team
|
|
<uri xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-core.html">http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-core.html</uri></para>
|
|
|
|
<para>[8] FreeBSD Handbook
|
|
<uri xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook">http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook</uri>
|
|
</para>
|
|
|
|
<para>[9] GNATS: The GNU Bug Tracking System
|
|
<uri xlink:href="http://www.gnu.org/software/gnats">http://www.gnu.org/software/gnats</uri>
|
|
</para>
|
|
|
|
<para>[10] FreeBSD PR Statistics
|
|
<uri xlink:href="http://www.FreeBSD.org/prstats/index.html">http://www.FreeBSD.org/prstats/index.html</uri></para>
|
|
|
|
<para>[11] NetBSD Developer Documentation: Release Engineering
|
|
<uri xlink:href="http://www.NetBSD.org/developers/releng/index.html">http://www.NetBSD.org/developers/releng/index.html</uri>
|
|
</para>
|
|
|
|
<para>[12] John Baldwin's FreeBSD Release Engineering Proposal
|
|
<uri xlink:href="http://people.FreeBSD.org/~jhb/docs/releng.txt">http://people.FreeBSD.org/~jhb/docs/releng.txt</uri>
|
|
</para>
|
|
|
|
<para>[13] PXE Jumpstart Guide
|
|
<uri xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html">http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/pxe/index.html</uri>
|
|
</para>
|
|
|
|
<para>[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic:
|
|
<link xlink:href="http://docs.FreeBSD.org/44doc/papers/releng.html">
|
|
<emphasis>The Release Engineering of 4.3BSD</emphasis></link>
|
|
</para>
|
|
</sect1>
|
|
</article>
|