diff options
Diffstat (limited to 'es_ES.ISO8859-1/books/handbook/policies/chapter.sgml')
| -rwxr-xr-x | es_ES.ISO8859-1/books/handbook/policies/chapter.sgml | 392 |
1 files changed, 0 insertions, 392 deletions
diff --git a/es_ES.ISO8859-1/books/handbook/policies/chapter.sgml b/es_ES.ISO8859-1/books/handbook/policies/chapter.sgml deleted file mode 100755 index d76ecbbe6d..0000000000 --- a/es_ES.ISO8859-1/books/handbook/policies/chapter.sgml +++ /dev/null @@ -1,392 +0,0 @@ -<!-- - El proyecto de documentación de FreeBSD - - $FreeBSD$ ---> - -<chapter id="policies"> - <title>Guías y políticas del árbol de código fuente</title> - - <para><emphasis>Contribución de &a.phk;.</emphasis></para> - - <para>Este capítulo documenta la política por la que se rige el - árbol de código fuente de FreeBSD.</para> - - <sect1 id="policies-maintainer"> - <title><makevar>MAINTAINER</makevar> en Makefiles</title> - - <para>Junio 1996.</para> - - <para>Si una parte en particular de la distribución FreeBSD es mantenida por - una persona o grupo de personas, pueden comunicar este hecho al mundo añadiendo - esta línea - - <programlisting> -MAINTAINER= email-addresses</programlisting> - - a los <filename>Makefile</filename>s que cubren esta parte del árbol de - código fuente.</para> - - <para>La semántica de es como sigue:</para> - - <para>El mantenedor posee y es responsable de ese código. Esto significa que - él es responsable de arreglar errores y responder reportes de problemas relacionados - con esa parte del código, y en el caso de contribución de software, de revisar - nuevas versiones, según sea necesario.</para> - - <para>Los cambios en directorios que tienen un mantenedor definido deberán ser - enviados al mantenedor para ser revisados antes de ser incluidos. - Sólo si el mantenedor no responde durante un periodo de tiempo inaceptable, a - varios mensajes, será aceptable incluir cambios sin la revisión del - mantenedor. Sin embargo, se sugiere que los cambios sean revisados por alguien más - si es posible.</para> - - <para>No es aceptable, por supuesto, añadir una persona o grupo como mantenedor a - menos que estén de acuerdo en asumir esta tarea. Por otro lado, no tiene - porqué ser un committer, pudiendo ser fácilmente un grupo de personas.</para> - </sect1> - - <sect1> - <title>Software de Contribución</title> - - <para><emphasis>Contribucion de &a.phk; y &a.obrien;.</emphasis></para> - - <para>Junio 1996.</para> - - <para>Algunas partes de la distribución de FreeBSD consisten en software - que está siendo mantenido activamente fuera del proyecto FreeBSD. Por razones - históricas, llamamos a esto software <emphasis>de contribución</emphasis>. - Algunos ejemplos son perl, gcc y patch.</para> - - <para>En los últimos dos años, se han usado diferentes métodos para - tratar con este tipo de software y todos tienen algunas ventajas e inconvenientes. No - ha emergido ningún claro ganador.</para> - - <para>Ya que este es el caso, después de algo de debate uno de estos - métodos ha sido seleccionado como el método “oficial” - y será requerido para futuras importaciones de este tipo de software. - Más aún, se sugiere firmemente que el software de contribución existente - converja con este modelo en el futuro, ya que tiene ventajas significativas - sobre el antiguo método, incluyendo la habilidad de obtener fácilmente - diferencias relativas a la versión “oficial” del fuente por todos - (aún sin acceso cvs). Esto hará significativamente mas fácil el - devolver cambios a los desarrolladores primarios del software de contribución.</para> - - <para>Finalmente, sin embargo, quedan las personas que están haciendo el - trabajo. Si usar este modelo es particularmente incompatible con el paquete con el cual - se trata, se pueden conceder excepciones a esta regla solo con la aprobación del - core team y con el consenso general de los otros desarrolladores. La habilidad de mantener - el paquete en el futuro será un asunto clave en las decisiones.</para> - - <note> - <para>Debido a algunas desafortunadas limitaciones de diseño con el formato de - archivo RCS y el uso de las ramas "vendors" con el CVS, son - <emphasis>fuertemente desaprobados</emphasis> cambios cosméticos, triviales y/o - menores en archivos que estén siendo seguidos por la rama "vendor". - Los "arreglos de sintaxis" están incluidos explícitamente aquí - bajo la categoría "cosméticos" y deben ser evitados en archivos con - revisión 1.1.x.x. El impacto que puede tener la modificación de un - sólo carácter en el repositorio puede ser bastante dramático.</para> - </note> - - <para>El lenguaje de programación <application>Tcl</application> será usado - como un ejemplo sobre como este modelo trabaja:</para> - - <para><filename>src/contrib/tcl</filename> contiene los fuentes distribuidos - por los mantenedores de este programa. Las partes que no son enteramente - aplicables a FreeBSD pueden ser eliminadas. En el caso del Tcl, los subdirectorios - <filename>mac</filename>, <filename>win</filename> y <filename>compat</filename> fueron - eliminados antes de la importación</para> - - <para><filename>src/lib/libtcl</filename> contiene sólo un <filename>Makefile</filename> - estilo bmake que usa las reglas estándar <filename>bsd.lib.mk</filename> makefile - para producir la librería e instalar la documentación.</para> - - <para><filename>src/usr.bin/tclsh</filename> contiene sólo un - <filename>Makefile</filename> estilo bmake que producirá e instalará - el programa <command>tclsh</command> y sus páginas man asociadas usando las - reglas estándar <filename>bsd.prog.mk</filename></para> - - <para><filename>src/tools/tools/tcl_bmake</filename> contiene un par de shell scripts que - pueden ser de ayuda cuando el software tcl necesita actualización. Estos no son - parte integral o de instalación del software.</para> - - <para>Lo importante aquí es que el directorio - <filename>src/contrib/tcl</filename> se crea de acuerdo a las reglas: - se supone que debe contener las fuentes tal y como se distribuyen (en una rama vendor - adecuada del CVS y sin expansión de claves RCS) con tan pocos cambios - específicos para FreeBSD como sea posible. La herramienta "easy-import" - (importación fácil) en freefall ayudará haciendo la - importación, pero si hay dudas acerca de como hacerlo, es imperativo que se pregunte - primero y no hacerlo esperando que “funcione”. El CVS no perdona accidentes de - importación y se requiere un gran esfuerzo para arreglar grandes errores.</para> - - <para>Debido a las limitaciones de diseño previamente mencionadas de las - ramas "vendor" del CVS, se requiere que los parches “oficiales” - del vendedor sean aplicados a los fuentes originales de distribución y el - resultado reimportado otra vez en la rama vendor correspondiente. Los parches oficiales - nunca deben ser usados en la versión disponible en el CVS de FreeBSD e integrados, - ya que esto destruye la coherencia de la rama vendor y hace que la importación de - futuras versiones sea más complicada por la aparición de conflictos. - </para> - - <para>Ya que muchos paquetes contienen archivos cuya intención es la - compatibilidad con otras arquitecturas y ambientes distintos a FreeBSD, - es permisible eliminar partes del árbol de distribución que no son de - interés para FreeBSD con el fin de ahorrar espacio. Los archivos que - contienen notas de copyright y notas de la versión, información en algo - aplicable a los archivos que quedan <emphasis>no</emphasis> deberán ser eliminados. - </para> - - <para>Si parece más fácil, los <command>bmake</command> - <filename>Makefile</filename>s pueden ser producidos automaticamente desde el árbol - de distribución por alguna utilidad, algo que podría hacer - aun más fácil el actualizar a una nueva versión. Si esto es hecho, - asegúrese de revisar tales utilidades (como sea necesario) en el directorio - <filename>src/tools</filename> junto con el mismo port para que esté disponible - para los futuros mantenedores.</para> - - <para>En el nivel de directorio <filename>src/contrib/tcl</filename> - debe ser añdido un archivo llamado <filename>FREEBSD-upgrade</filename> - debiendo presentar cosas como:</para> - - <itemizedlist> - <listitem> - <para>Qué archivos se han dejado fuera de la importación</para> - </listitem> - - <listitem> - <para>De donde fue obtenida la distribución original y/o el - servidor oficial principal.</para> - </listitem> - - <listitem> - <para>Dónde enviar parches a los autores originales</para> - </listitem> - - <listitem> - <para>Una visión general de los cambios específicos que se han hecho - para FreeBSD.</para> - </listitem> - </itemizedlist> - - <para>Sin embargo, por favor no importar <filename>FREEBSD-upgrade - (actualización)</filename> con los fuentes de contribución. En su lugar, - usar <command>cvs add FREEBSD-upgrade ; cvs ci</command> después del prompt - inicial. Más abajo existe un ejemplo de sintaxis de - <filename>src/contrib/cpio</filename>:</para> - - <programlisting> -Este directorio contiene códigos fuente virgen de los archivos originales de -distribución en una rama "vendor". No tratar, bajo ninguna circunstancia, -de actualizar los archivos en este directorio con parches y un cvs commit. -Nuevas versiones o versiones oficiales de parches deben ser importadas. -Por favor recuerdar importar con "-ko" para prevenir que el CVS corrompa -el Id del RCS de algun vendor. - -Para la importación del GNU cpio 2.4.2, se eliminaron los siguientes archivos: - - INSTALL cpio.info mkdir.c - Makefile.in cpio.texi mkinstalldirs - -Para actualizar a una versión más nueva de cpio, cuando esté disponible: - 1. Descomprimir la nueva versión en un directorio vacío. - [No hacer NINGUN cambio a los archivos.] - - 2. Eliminar los archivos listados arriba y cualquier otro que no se relacione - con FreeBSD. - - 3. Usar el comando: - cvs import -ko -m 'Virgin import of GNU cpio v<version>' \ - src/contrib/cpio GNU cpio_<version> - - Por ejemplo, para importar la versión 2.4.2, usar: - cvs import -ko -m 'Virgin import of GNU v2.4.2' \ - src/contrib/cpio GNU cpio_2_4_2 - - 4. Seguir las instrucciones del paso 3 para resolver cualquier conflicto entre - cambios locales de FreeBSD y la nueva versión. - -NO desviarse, bajo ninguna circunstancia, de este procedimiento. - -Para hacer cambios locales al cpio, simplemente aplicar el patch y commit a la rama -principal (también conocida como HEAD). Nunca hacer cambios locales -en la rama GNU. - -Todos los cambios locales deberían ser enviados a "cpio@gnu.ai.mit.edu" para -su inclusión en la nueva versión release. - -obrien@FreeBSD.org - 30 March 1997</programlisting> - </sect1> - - <sect1 id="policies-encumbered"> - <title>Archivos "adicionales" (encumbered)</title> - - <para>Ocasionalmente podría ser necesario incluir un archivo "adicional" en el - código fuente de FreeBSD. Por ejemplo, si un dispositivo requiere que una - pequeña pieza de código binario sea cargada antes de que el dispositivo - funcione, y no tenemos los fuentes de ese código, entonces se dice que el archivo - binario es "encumbered". - Las siguientes políticas se aplican al incluir archivos encumbered en - en el árbol fuente FreeBSD.</para> - - <orderedlist> - <listitem> - <para>Cualquier archivo que sea interpretado o ejecutado por la CPU del - sistema y no en formato fuente es encumbered.</para> - </listitem> - - <listitem> - <para>Cualquier archivo con una licencia más restrictiva que BSD o GNU - es encumbered.</para> - </listitem> - - <listitem> - <para>Un archivo que contiene datos binarios descargables para que el - hardware lo use no es encumbered, a menos que (1) o (2) se apliquen - a él. Debe ser guardado en un formato ASCII neutral a la arquitectura - (se recomienda file2c o uuencodeado).</para> - </listitem> - - <listitem> - <para>Cualquier archivo encumbered requiere aprobación específica del - <link linkend="staff-core">Core team</link> antes de ser añadido al - repositorio CVS.</para> - </listitem> - - <listitem> - <para>Los archivos encumbered van en <filename>src/contrib</filename> - o <filename>src/sys/contrib</filename>.</para> - </listitem> - - <listitem> - <para>El módulo entero debería ser mantenido en su conjunto. No hay excusa en - separarlo, a menos que haya intercambio de código con código no encumbered. - </para> - </listitem> - - <listitem> - <para>Los archivos objeto son nombrados - <filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename> - .</para> - </listitem> - - <listitem> - <para>Archivos del Kernel:</para> - - <orderedlist> - <listitem> - <para>Siempre deben ser referenciados en <filename>conf/files.*</filename> (para - simplicidad del build).</para> - </listitem> - - <listitem> - <para>Siempre debería estar en <filename>LINT</filename>, pero el <link - linkend="staff-core">Core team</link> decide caso por caso si - debería ser comentado o no. El <link - linkend="staff-core">Core team</link> puede, por supuesto, cambiar - su opinión más adelante.</para> - </listitem> - - <listitem> - <para>El <link linkend="staff-who">Ingeniero de Release</link> - decide si va o no a la release.</para> - </listitem> - </orderedlist> - </listitem> - - <listitem> - <para>Archivos de usuario:</para> - - <orderedlist> - <listitem> - <para>El <link linkend="staff-core">Core team</link> decide si - el código debería ser parte de <command>make world</command>.</para> - </listitem> - - <listitem> - <para>El <link linkend="staff-who">Ingeniero de la Release</link> - decide si va a la release.</para> - </listitem> - </orderedlist> - </listitem> - </orderedlist> - </sect1> - - <sect1 id="policies-shlib"> - <title>Librerías compartidas</title> - - <para><emphasis>Contribuido por &a.asami;, &a.peter;, y &a.obrien; 9 - Diciembre 1996.</emphasis></para> - - <para>Si se está añadiendo soporte para librerías compartidas a un puerto u - otra pieza de software que no tiene uno, los números de versión deben - seguir estas reglas. Generalmente, los números resultantes no tendrán nada - que ver con la versión release del software.</para> - - <para>Los tres principios de la construcción de librerías compartidas son:</para> - - <itemizedlist> - <listitem> - <para>Comenzando desde <literal>1.0</literal></para> - </listitem> - - <listitem> - <para>Si hay un cambio que sea compatible con versiones anteriores, - eliminar el número menor</para> - </listitem> - - <listitem> - <para>Si hay un cambio incompatible, quitar el número mayor</para> - </listitem> - </itemizedlist> - - <para>Por ejemplo, funciones añadidas y solució de errores resultan en la - eliminación del numero de versión menor, mientras que las funciones borradas, - sintaxis cambiada de llamada de función, etc, forzarán que el número - de versión mayor cambie.</para> - - <para>Usar los números de versión de la forma mayor.menor - (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Nuestro - lincador dinámico no gestiona correctamente números de versión - de la forma <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable> - . Cualquier número de versión después de <replaceable>y</replaceable> - (es decir, el tercer dígito) es totalmente ignorado cuando - se comparan números de versión de librerías compartidas - para decidir con que librería enlazar. Dadas 2 librerías compartidas - que difieren sólo en la “micro” revisión, - <command>ld.so</command> enlazará con la mas alta. Es decir: - si se enlaza con <filename>libfoo.so.3.3.3</filename>, el lincador - sólo reconoce <literal>3.3</literal> en los encabezados, - y enlazará con cualquiera que comience con <replaceable>libfoo.so.3</replaceable>. - <replaceable>(cualquier cosa >=3)</replaceable>.<replaceable>(el más alto - disponible)</replaceable>.</para> - <note> - <para><command>ld.so</command> siempre usará la revisión - “menor” más alta. Es decir: usará - <filename>libc.so.2.2</filename> en preferencia a - <filename>libc.so.2.0</filename>, aun si el programa estaba - inicialmente enlazado con <filename>libc.so.2.0</filename>.</para> - </note> - - <para>Para librerías no portables, es también nuestra política cambiar - el número de versión de librería compartida solo una vez entre releases. - Cuando se hace un cambio a una librería del sistema que requiere - que se quite el número de versión, revisar los logs commit del - <filename>Makefile</filename>. Es responsabilidad del miembro del commit asegurarse de que - el primer cambio desde la release hará que se actualice el número de versión - de la librería compartida en el <filename>Makefile</filename>, y cualquier - subsecuente cambio no lo hará.</para> - </sect1> -</chapter> - -<!-- - Local Variables: - mode: sgml - sgml-declaration: "../chapter.decl" - sgml-indent-data: t - sgml-omittag: nil - sgml-always-quote-attributes: t - sgml-parent-document: ("../book.sgml" "part" "chapter") - End: ---> |