2. Cómo Colaborar

2.1. Informes de Errores y Comentarios Generales

Las ideas o sugerencias de interés técnico general deben enviarse a lista de correo de discusiones técnicas en FreeBSD. En consecuencia, si le interesan ese tipo de cuestiones (¡y no le importa recibir un gran volumen de correo!) debería suscribirse a la lista de correo de discusiones técnicas en FreeBSD enviando un correo electrónico a <majordomo@FreeBSD.org>. Consulte el FreeBSD Handbook para más información sobre ésta y otras listas de correo.

Si encuentra un error o quiere enviar un cambio concreto por favor utilice el programa send-pr(1) o su equivalente en la web (N. del T.: El interfaz web de send-pr fué desactivado a causa del “spam”). Trate de rellenar todos los campos del informe de errores. A menos que exceda de 65KB puede incluír los parches directamente en el informe. Si es posible aplicar el parche al árbol de fuentes no olvide incluír [PATCH] en la sinópsis del informe. Cuando incluya parches no “copie y pegue” ya que las tabulaciones son transformadas en espacios, haciendo el parche inútil. Considere la posibilidad de comprimir los parches mediante uuencode(1) si sobrepasan los 20KB.

Tras rellenar el informe debería recibir un mensaje de confirmación junto con un número de seguimiento. Conserve ese número por si en algún momento pudiera añadir nueva información sobre el problema enviando correo a <FreeBSD-gnats-submit@FreeBSD.org>. Utilice el número como asunto del mensaje (por ejemplo, "Re: kern/3377". Así debería enviarse la información adicional sobre cualquier PR.

Si no recibe confirmación en un período de tiempo razonable (entre 3 días y una semana, dependiendo de su tipo de conexión) o si por alguna razón no puede utilizar el comando send-pr(1), puede solicitar que alguien lo haga por usted enviando un correo a lista de 'problem reports' de FreeBSD.

No olvide consultar éste “article” sobre cómo escribir buenos informes de problemas.

2.2. Cambios en la Documentación

Los cambios en la documentación son revisados por la lista de correo del proyecto de documentación de FreeBSD. Por favor, consulte FreeBSD Documentation Project Primer para recibir instrucciones detalladas. Envíe nuevos contenidos o cambios sobre los ya existentes (¡incluso los pequeños son bienvenidos!) mediante send-pr(1) tal y como se detalla en Informes de Error y Comentarios Generales.

2.3. Cambios al Código Fuente ya Existente

Añadir cambios o modificar el código fuente existente es un tema delicado y depende mucho de hasta qué punto esté usted al día sobre el estado actual del desarrollo de FreeBSD. Hay una versión en desarrollo permanente de FreeBSD conocida como “FreeBSD-CURRENT”, disponible de muy diversas formas para mayor comodidad de los desarrolladores que están trabajando activamente en el sistema. Consulte el FreeBSD Handbook, donde se explica cómo obtener y utilizar FreeBSD-CURRENT.

Si trabaja con versiones anticuadas de los fuentes desafortunadamente significará que sus cambios podrían con frecuencia resultar demasiado obsoletos o demasiado divergentes para una fácil reintegración dentro de FreeBSD. Ésta posibilidad puede minimizarse suscribiéndose a la lista de anuncios importantes del Proyecto FreeBSD y a la FreeBSD-CURRENT lista de correo, donde tienen lugar los debates sobre el estado actual del sistema.

Asumiendo que puede manejarse con seguridad con unos fuentes totalmente actualizados sobre los que aplicar sus cambios, el siguiente paso es generar los “diffs” que enviará al equipo de FreeBSD. Hágalo con el comando diff(1).

El formato diff(1) que preferimos para el envío de parches es la salida unificada generada por diff -u. Sin embargo, para parches que implican cambios sustanciales en una región de código una salida contextual de “diff” generada por diff -c resultará más legible y en consecuencia preferible.

Por ejemplo:

% diff -c ficheroantíguo ficheronuevo

o

% diff -c -r directorioantíguo directorionuevo

generarían un conjunto de “diffs” contextuales de fichero fuente o la jerarquía de directorios.

Del mismo modo

% diff -u ficheroantíguo ficheronuevo

o

% diff -u -r directorioantíguo directorionuevo

nos darían el mismo resultado excepción hecha del formato unificado de los “diffs” resultantes.

Consulte la página man de diff(1) para más detalles.

Una vez que disponga de un conjunto de “diffs ” (que debería probar con el comando patch(1)) puede enviarlos para que sean incluídos en FreeBSD. Utilice el programa send-pr(1) tal y como se muestra Informes de Errores y Comentarios Generales. ¡No se limite simplemente a enviar sus “diffs” a la lista de correo de discusiones técnicas en FreeBSD o se perderán! Agradecemos inmensamente su colaboración (¡éste es un proyecto que funciona gracias al trabajo desinteresado de mucha gente!). Estamos muy ocupados, así que no podemos atender inmediatamente todos y cada uno de los envíos recibidos, pero permanecerán en la “PR database” hasta que lo hagamos. Etiquete sus envíos incluyendo [PATCH] en la sinópsis del informe.

Si lo considera oportuno (ésto es, si ha añadido borrado o renombrado ficheros) empaquete sus cambios en un fichero tar y ejecute el programa uuencode(1) sobre él. Puede usar también ficheros creados con shar(1)

Si su cambio puede tener un cariz potencialmente delicado ésto es, no está seguro de bajo qué tipo de “licencia” sería su distribución ulterior o simplemente no está listo para liberarlo sin una revisión exhaustiva, debería enviarlo directamente a FreeBSD core team en lugar de usar send-pr(1). El FreeBSD core team incluye un grupo de gente mucho más pequeño que lleva a cabo la mayor parte del trabajo diario en FreeBSD. Tenga en cuenta que el FreeBSD core team está muy ocupado y por lo tanto sólo debería enviársele correo cuando sea estrictamente necesario.

Consulte la páginas “man” de intro(9) y style(9) para saber más acerca del estilo de codificación requerido. Le agradeceríamos mucho que al menos tuviera en cuenta esa información antes de enviar código.

2.4. New Code or Major Value-Added Packages

En el caso de una contribución significativa o de gran impacto, o si se trata de añadir una nueva característica importante a FreeBSD, enviar ficheros tar tratados con “uuencode” o por el contrario ponerlos a disposición de otras personas en un sitio web o FTP se convierte en algo prácticamente imprescindible. Si no dispone de acceso a un sitio web o FTP pregunte en la lista apropiada de FreeBSD para que alguien se lo facilite.

Cuando se trabaja con un gran volumen de código el espinoso tema de la “licencia” invariablemente sale a la palestra. Las “licencias” admitidas para la inclusión de código en FreeBSD son:

1. La licencia BSD. Ésta licencia es la preferida a causa de su naturaleza carente de “requerimientos añadidos” y su atractivo general para la empresa. Lejos de buscar evitar el uso comercial, el Proyecto FreeBSD recomienda vivamente la participación de entidades comerciales que pudieran en casos determinados dedicar parte de sus recursos a FreeBSD.

2. La GNU General Public License, o “GPL”. Ésta licencia no es tan popular debido al esfuerzo añadido que requiere de cualquiera que usara el código con fines comerciales, pero dada la ingente cantidad de código GPL que usamos habitualmente (el compilador, el ensamblador, el procesador de texto, etc) sería estúpido rechazar contribuciones bajo ésta licencia. El código bajo licencia GPL también se incluye bajo una parte diferenciada del árbol, pudiendo ser /sys/gnu o /usr/src/gnu, y es por tanto fácilmente identificable para quienes la licencia GPL suponga un problema.

Todo lo que vaya bajo cualquier otro tipo de licencia requiere que ésta deba ser cuidadosamente revisada antes de que su inclusión en FreeBSD sea llevada a consideración. Las aportaciones bajo licencias comerciales particularmente restrictivas en vigor por lo general son rechazadas aunque siempre se recomienda a los autores que hagan públicamente accesible su trabajo usando sus propios medios.

Para poner su trabajo bajo la licencia “BSD” inserte el siguiente texto al principio de todos y cada uno de los ficheros de código que quiera amparar bajo la misma, reemplazando el texto entre %% con la información apropiada:

Copyright (c) %%años_exactos%%
        %%su_nombre%%, %%su_estado/país%%  %%su_código_postal%%.
	All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer as
   the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY %%su_nombre%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%su_nombre%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

        $Id$

Para su comodidad existe una copia de éste texto en /usr/share/examples/etc/bsd-style-copyright.

2.5. Dinero, Hardware o Acceso a Internet

Estamos encantados de aceptar donaciones económicas para ayudar a impulsar el Proyecto FreeBSD y, como en cualquier proyecto mantenido por voluntarios, un poco puede hacer mucho. También son muy importantes las donaciones de hardware para ampliar nuestra lista de hardware soportado, dado que normalmente andamos cortos de fondos con los que comprar ese tipo de material.