Contribuir a FreeBSD

---

1.1. Tareas en Curso para No Programadores

Una gran parte de quienes trabajan en FreeBSD no son programadores. El Proyecto incluye escritores de documentación, diseñadores y técnicos de soporte. Los únicos requisitos necesarios son poner algo de su tiempo y ganas de aprender.

1. Lea cuidadosamente las FAQ y el Handbook cada cierto tiempo. Si algo está mal explicado, desfasado o sencillamente completamente equivocado háganoslo saber. Aún mejor, envíenos la corrección (no es difícil aprender SGML pero no hay problema si lo envía en ASCII).

2. Ayude a traducir la documentación de FreeBSD a su lengua materna. Si ya existe documentación en su idioma puede ayudar a traducir otros documentos o a mantener al día los que ya existan. Antes de nada consulte Translations FAQ en el “FreeBSD Documentation Project Primer”. El hecho de traducir algo no implica la obligación de traducir todo: al ser una tarea voluntaria puede usted traducir tanto o tan poco como prefiera. Cuando alguien empieza a traducir casi siempre hay alguien que se une. Si sólo tiene tiempo o ganas para traducir una parte de la documentación por favor, traduzca las instrucciones de instalación.

3. Lea la lista de correo para preguntas generales sobre FreeBSD y el grupo de noticias comp.unix.bsd.freebsd.misc de vez en cuando (o incluso regularmente). Compartir sus conocimientos mientras ayuda a la gente a resolver sus problemas puede ser muy gratificante. ¡Puede ser que incluso aprenda usted también algo nuevo! Esos foros pueden ser también un importante foco de ideas para nuevas cosas en las que trabajar.

---

1.2. Tareas en Curso para Programadores

La mayoría de las tareas aquí expuestas requieren una considerable cantidad de tiempo o un conocimiento profundo del kernel de FreeBSD o ambas cosas. Existen, sin embargo, multitud de tareas muy útiles que son ideales para “hackers de fin de semana”.

1. Si utiliza FreeBSD-CURRENT y tiene una buena conexión con Internet existe una máquina llamada current.FreeBSD.org que genera diariamente (en teoría, la frecuencia puede variar) una distribución completa. Intente instalar la última versión desde ella e informe de cualquier anomalía en el proceso.

2. Lea la lista de 'problem reports' de FreeBSD. Puede encontrar algún problema sobre el que hacer un comentario constructivo o sobre el que probar parches. Puede incluso intentar arreglarlo usted.

3. Si sabe de alguna corrección que ha sido aplicada con éxito a -CURRENT pero que aún no haya sido incluída en -STABLE tras un período de tiempo razonable (por lo general un par de semanas) envíe al committer responsable un (educado) mensaje recordándoselo.

4. Mueva software de terceras partes a src/contrib en el árbol de fuentes.

5. Asegúrese de que el código de src/contrib está actualizado.

6. Compile el árbol de fuentes (o sólo una parte del mismo) con una cantidad extra de “warnings ” activadas y depúrelas.

7. Corrija “warnings” en los ports en los que aparecen cosas en desuso como gets() o que incluyen malloc.h.

8. Si ha enviado algún port envíe sus parches a los autores originales: le hará la vida más fácil cuando liberen la siguiente versión.

9. Consiga copias de estándares formales como POSIX. Hay enlaces relacionados con esos estándares en el sitio web del FreeBSD C99 & Posix Standards Conformance Project. Compare el funcionamiento interno de FreeBSD con el que exije el estándar. Si hay diferencias, en especial en algún rincón sutil y oscuro de la especificación, envíe un PR (“Problem Report”). Si es capaz de aventurar una solución incluya un parche en el PR. Si cree que el estándar es incorrecto póngase en contacto con los responsables del mismo para que tengan en cuenta su propuesta.

10. ¡Sugiera nuevas tareas para ésta lista!

---

1.3. Trabajo en la “PR Database”

La lista de PR de FreBSD muestra los informes de problemas activos así como las peticiones de mejoras que han enviado los usuarios de FreeBSD. La “PR database” incluye tanto problemas que han de ser corregidos por programadores como por no programadores. Busque entre los PR que están abiertos, puede haber alguno que le interese. Algunos pueden ser tareas muy sencillas que sólo necesiten una mirada adicional para confirmar que la solución adjunta es la adecuada. Otras, por el contrario, pueden llegar a ser muchísimo más complejas o incluso no incluír una solución.

Comience con un PR no haya sido aún asignado. Si el PR ya ha sido asignado a alguien pero cree que puede ayudar envíe un correo electrónico a la persona responsable del PR y pregúntele si puede colaborar (tal vez ya exista un parche listo para ser probado o puedan contrastar ideas).

---

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.