Author: jmpuerta Date: Tue Aug 21 06:10:15 2007 New Revision: 1055 Log: First translation of the whole appendix D. To be reviewed.
Modified: trunk/es/appd.xml Modified: trunk/es/appd.xml ============================================================================== --- trunk/es/appd.xml (original) +++ trunk/es/appd.xml Tue Aug 21 06:10:15 2007 @@ -1,111 +1,111 @@ <appendix id="bug-reporting"> -<title>Example Instructions for Reporting Bugs</title> +<title>Ejemplo de Instrucciones para Informar sobre Fallos</title> <simplesect> -<para>This is a lightly-edited copy of the Subversion project's online -instructions to new users on how to report bugs. See -<xref linkend="users-to-volunteers"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase> for why it is -important that a project have such instructions. The original -document is located at +<para>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 <xref linkend="users-to-volunteers"/><phrase output="printed"> en +<xref linkend="managing-volunteers"/></phrase> para saber porque es importante +que un proyecto tenga tales instrucciones. El documento original se localiza en <ulink url="http://svn.collab.net/repos/svn/trunk/www/bugs.html"/>.</para> <screen> - Reporting Bugs in Subversion + Informar sobre Fallos en Subversion -This document tells how and where to report bugs. (It is not a list of -all outstanding bugs — you can get that here instead.) +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í) -Where To Report A Bug ---------------------- +Dónde informar sobre un fallo +----------------------------- - * If the bug is in Subversion itself, send mail to - [EMAIL PROTECTED] Once it's confirmed as a bug, - someone, possibly you, can enter it into the issue tracker. (Or - if you're pretty sure about the bug, go ahead and post directly - to our development list, [EMAIL PROTECTED] But if - you're not sure, it's better to post to users@ first; someone - there can tell you whether the behavior you encountered is - expected or not.) + * Si el fallo está en el propio Subversion, mandar un correo a + [EMAIL PROTECTED] Una vez que se ha confirmado que es + un fallo, alguién, 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, + [EMAIL PROTECTED] Preo si no estás seguro, es mejor que se + publique primero en users@; ahí alguién puede decirte si el comportamiento + que se encontró es el esperado o no.) - * If the bug is in the APR library, please report it to both of - these mailing lists: [EMAIL PROTECTED], [EMAIL PROTECTED] + * Si el fallo esta en la librería APR, por favor informálo en estás + dos listas de correo: [EMAIL PROTECTED], [EMAIL PROTECTED] - * If the bug is in the Neon HTTP library, please report it to: + * Si el fallo está en la librería de HTTP Neon, por favor infórmalo en: [EMAIL PROTECTED], [EMAIL PROTECTED] - * If the bug is in Apache HTTPD 2.0, please report it to both of - these mailing lists: [EMAIL PROTECTED], - [EMAIL PROTECTED] The Apache httpd developer mailing - list is high-traffic, so your bug report post has the - possibility to be overlooked. You may also file a bug report at - http://httpd.apache.org/bug_report.html. - - * If the bug is in your rug, please give it a hug and keep it snug. - -How To Report A Bug -------------------- - -First, make sure it's a bug. If Subversion does not behave the way you -expect, look in the documentation and mailing list archives for -evidence that it should behave the way you expect. Of course, if it's -a common-sense thing, like Subversion just destroyed your data and -caused smoke to pour out of your monitor, then you can trust your -judgement. But if you're not sure, go ahead and ask on the users -mailing list first, [EMAIL PROTECTED], or ask in IRC, -irc.freenode.net, channel #svn. - -Once you've established that it's a bug, the most important thing you -can do is come up with a simple description and reproduction -recipe. For example, if the bug, as you initially found it, involves -five files over ten commits, try to make it happen with just one file -and one commit. The simpler the reproduction recipe, the more likely a -developer is to successfully reproduce the bug and fix it. - -When you write up the reproduction recipe, don't just write a prose -description of what you did to make the bug happen. Instead, give a -literal transcript of the exact series of commands you ran, and their -output. Use cut-and-paste to do this. If there are files involved, be -sure to include the names of the files, and even their content if you -think it might be relevant. The very best thing is to package your -reproduction recipe as a script, that helps us a lot. - -<emphasis>Quick sanity check: you *are* running the most recent version of -Subversion, right? :-) Possibly the bug has already been fixed; you -should test your reproduction recipe against the most recent -Subversion development tree.</emphasis> - -In addition to the reproduction recipe, we'll also need a complete -description of the environment in which you reproduced the bug. That -means: - - * Your operating system - * The release and/or revision of Subversion - * The compiler and configuration options you built Subversion with - * Any private modifications you made to your Subversion - * The version of Berkeley DB you're running Subversion with, if any - * Anything else that could possibly be relevant. Err on the side - of too much information, rather than too little. - -Once you have all this, you're ready to write the report. Start out -with a clear description of what the bug is. That is, say how you -expected Subversion to behave, and contrast that with how it actually -behaved. While the bug may seem obvious to you, it may not be so -obvious to someone else, so it's best to avoid a guessing game. Follow -that with the environment description, and the reproduction recipe. If -you also want to include speculation as to the cause, and even a patch -to fix the bug, that's great — see -http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches for -instructions on sending patches. - -Post all of this information to [EMAIL PROTECTED], or if you -have already been there and been asked to file an issue, then go to -the Issue Tracker and follow the instructions there. - -Thanks. We know it's a lot of work to file an effective bug report, -but a good report can save hours of a developer's time, and make the -bug much more likely to get fixed. + * Si el fallo está en el Apache HTTPD 2.0, por favor infórmalo en + estás dos listas de correo: [EMAIL PROTECTED], + [EMAIL PROTECTED] 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, asegurate 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, [EMAIL PROTECTED], 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. + +<emphasis>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.</emphasis> + +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://svn.collab.net/repos/svn/trunk/www/hacking.html#patches +con las instrucciones para mandar parches. + +Publica toda esta información en [EMAIL PROTECTED], 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. </screen> </simplesect> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
