Esto es una copia editada ligeramente de las instrucciones en línea del proyecto Subversion para nuevos usuarios sobre cómo informar sobre fallos. Ver “Treat Every User as a Potential Volunteer” en Capítulo 8, Coordinando a los Voluntarios para saber porque es importante que un proyecto tenga tales instrucciones. El documento original se localiza en http://svn.collab.net/repos/svn/trunk/www/bugs.html.
Informar sobre Fallos en Subversion
Este documento explica cómo y dónde informar sobre fallos. (no es una lista
de todos los fallos pendientes - pero se puede conseguir eso aquí)
¿Dónde informar sobre un fallo?
-----------------------------
* Si el fallo está en el propio Subversion, mandar un correo a
users@subversion.tigris.org. Una vez que se ha confirmado que es
un fallo, alguien, posiblemente tú, puede introducirlo en el
gestor de ""ejemplares"". (o si estás bastante seguro del fallo,
sigue adelante y publicalo directamente en nuestra lista de desarrollo,
dev@subversion.tigris.org. Preo si no estás seguro, es mejor que se
publique primero en users@; allí alguien puede decirte si el comportamiento
que se encontró es el esperado o no.)
* Si el fallo está en la librería APR, por favor infórmalo en estas
dos listas de correo: dev@apr.apache.org, dev@subversion.tigris.org.
* Si el fallo está en la librería de HTTP Neon, por favor infórmalo en:
neon@webdav.org, dev@subversion.tigris.org.
* Si el fallo está en el Apache HTTPD 2.0, por favor infórmalo en
estas dos listas de correo: dev@httpd.apache.org,
dev@subversion.tigris.org. La lista de correo para el desarrollador de
Apache httpd tiene mucho tráfico, así que tu publicación del informe
del fallo puede que sea pasada por alto. También debes introducir
un informe del fallo en http://httpd.apache.org/bug_report.html.
* Si el fallo está en tu ""alfombra"", por favor dale un abrazo y
déjalo ""cómodo"".
¿Cómo informar sobre un fallo?
----------------------------
Primero, asegúrate de que es un fallo. Si Subversion no se comporta como esperas,
mira la documentación y los archivos de las listas de correo buscando alguna
evidencia que indique que debería comportarse como esperas. Por supuesto,
si es una cosa de sentido común, como que Subversion ha destruído tus datos
y ha hecho que salga humo de tu monitor, entonces puedes fiarte de tu juicio.
Pero si no estás seguro, sigue adelante y pregunta primero en las lista
de correo de usuarios, users@subversion.tigris.org, o pregunta en IRC,
irc.freenode.net, en el canal #svn.
Una vez que has demostrado que es un fallo, lo más importante que debes hacer
es proponer una descripción simple y una receta para reproducirlo. Por ejemplo,
si el fallo, como lo encontraste inicialmente, implica cinco ficheros
sobre diez cambios, intenta hacer que se reproduzca con solo un fichero
y un cambio. Cuanto más simple es la receta para reproducirlo, más
probable es que un desarrollador tenga éxito al reproducir el fallo
y en arreglarlo.
Cuando escribas la receta para reproducirlo, no escribas una descripción
inversa de lo que hiciste para que ocurriera el fallo. Por el contrario,
da una transcripción literal de la serie exacta de comandos que ejecutaste,
y sus salidas. Utiliza la función cortar-y-pegar para este fin. Si hay ficheros
implicados, asegurate incluir los nombres de los ficheros, e incluso su
contenido si piensas que podría ser relevante. Lo mejor es empaquetar
tu receta para reproducirlo en un archivo de comandos, lo cual ayuda mucho.
Una sana comprobación rápida: ¿*estás* utilizando la versión más
reciente de Subvesion?, ¿no? :-) Posiblemente el fallo ya se ha corregido;
deberías probar tu receta para reproducir el fallo en el árbol de desarrollo
de Subversión más reciente.
Además de la receta para reproducirlo, también necesitaremos una
descripción completa del entorno donde se reprodució el error.
Esto es:
* Tu sistema operativo
* La versión liberada y/o revisión de Subversion
* El compilador y las opciones de configuración con las que ""construíste"" Subversion
* Cualquier modificación personal que hiciste a Subversion
* La versión de la BD de Berkeley con la que estás corriendo Subversion, si usas un BD
* Cualquier otra cosa que podría ser posiblemente relevante. Mejor tener demasiada información
más que tener demasiada poca.
Una vez que tienes todo esto, estás listo para escribir el informe. Empieza
con una descripción clara del fallo en si. Es decir, di como esperabas que
Subversion se comportara, y contrástalo con como realmente se comportó.
Aunque el fallo puede parecerte obvio a ti, puede no ser tan obvio para
otra persona, por tanto es mejor evitar las adivinanzas. Sigue con la descripción
del entorno, y la receta para reproducirlo. Si también quieres incluir
alguna especulación sobre la causa, e inclusive un parche para arreglar
el problema, sería genial - ver http://subversion.apache.org/docs/community-guide/#patches
con las instrucciones para mandar parches.
Publica toda esta información en dev@subversion.tigris.org, o si ya lo has hecho
y has pedido que se publique un ""ejemplar"", entonces ve al Gestor de ""Ejemplares""
y sigue las instrucciones de allí.
Gracias. Sabemos que es mucho trabajo publicar un informe de fallos efectivo,
pero a un buen informe puede ahorrar horas de tiempo a un desarrollador,
y hace que los fallos tengan más probabilidad de ser arreglados.