Bug reporting guidelines (Español)

Estado de la traducción: esta traducción de Bug reporting guidelines fue revisada el 2021-03-06. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Iniciar (y cerrar) reportes de fallos en el Arch Linux Bugtracker es una de las varias maneras posibles de ayudar a la comunidad. Pero, los reportes mal hechos pueden terminar siendo contraproducentes. Cuando se reportan fallos de manera incorrecta, los desarrolladores gastan tiempo investigando y cerrando reportes inválidos. Este documento va a guiar a cualquiera que quiera ayudar a la comunidad reportando y buscando fallos de manera eficaz.

Vea también: Como reportar fallos de manera efectiva por Simon Tatham.

Antes de reportar

No es difícil preparar un reporte de fallos detallado y bien hecho, pero requiere un esfuerzo por parte de la persona que reporta. Podría decirse que el trabajo hecho antes de reportar un fallo es la parte más útil del trabajo. Desafortunadamente, pocos se toman el tiempo para hacerlo correctamente.

Los siguientes pasos lo van a guiar en como preparar su reporte de fallos o su petición de características.

Buscar reportes duplicados

Si encuentra un problema o quiere una nueva característica, es muy probable que alguien ya haya pasado por este problema o se le haya ocurrido esa idea. Si así es, puede que ya exista un reporte apropiado. En este caso, no cree otro reporte; si no, vea #Siguiendo los reportes.

Busque bien por información existente, incluyendo en:

Foros de Arch Linux: Los foros son la primera parada para los usuarios que buscan ayuda y compartir ideas. Mientras que una solución puede no existir aún, la información y discusión adicional puede llevarlo por el camino correcto.
Arch Linux Bugtracker: Su problema puede ya haber sido reportado a los desarrolladores de Arch Linux. Los reportes de fallos duplicados no son útiles y son cerrados de manera rápida. Busque tanto reportes abiertos como cerrados seleccionando «All Statuses» en Advanced. Recuerde seleccionar «search details» y/o «search comments» en Advanced, puede que el titulo del reporte no tenga el texto que está buscando.
Google o su motor de búsqueda preferido: Busque ocupando el nombre del programa, versión, y alguna parte relevante del mensaje, si es que tiene.
Foros, listas de difusión, o registro de fallos de la aplicación: Si Arch Linux no es responsable por el fallo, debe ser reportado por los medios de la aplicación en vez de el Arch Linux Bugtracker. Busque tanto en los reportes cerrados recientemente como en los abiertos. Puede que los fallos estén corregidos en la versión de desarrollo del programa.
Foros de otras distribuciones: La comunidad del software libre es vasta; ¡los «Archers» no son los únicos usuarios con ideas! Considere buscar en los Foros de Gentoo, FedoraForum.org, y los Foros de Ubuntu, por ejemplo.

¿Upstream o Arch?

Arch Linux es una distribución de GNU/Linux. Los desarrolladores de Arch Linux y los Trusted Users son responsables de compilar, empaquetar, y distribuir software de una gran cantidad de fuentes. Upstream se refiere a las fuentes – los autores originales o mantenedores del software distribuido en Arch Linux. Por ejemplo, el navegador Firefox es desarrollado por Mozilla Project.

Si Arch no es responsable por el fallo, el problema no va a ser solucionado reportandolo a los desarrolladores de Arch. La responsabilidad de un fallo cae en los desarrolladores/mantenedores cuando no es causado por el intento de distribuirlo e integrarlo de la distribución.

Al reportar los fallos a los desarrolladores, no solo ayuda a «Archers» y a los desarrolladores de Arch, si no que también ayuda a más personas en la comunidad del software libre porque la solución va a llegar a todos los distribuidores.

Después de reportar el fallo a los desarrolladores o si encuentra información relevante, puede ser útil publicarlo en el Arch Linux Bugtracker para los desarrolladores de Arch y los usuarios sepan de ello.

Entonces, ¿de que es responsable Arch Linux?:

Arch Linux Projects: pacman, AUR, mkinitcpio y los sitios web de Arch. Si tiene dudas con respecto si un proyecto pertenece a Arch Linux o no, vea la información del paquete (pacman -Qi package_name o usando la pagina) y vea la fuente.
Empaquetado: El empaquetado básicamente consiste en conseguir el código desde la fuente, compilarlo con las opciones relevantes, asegurarse que va a instalarse correctamente en un sistema Arch, y ver si la funcionalidad básica está presente. Empaquetarlo para Arch no significa agregarle características nuevas o parches para los fallos existentes; ese es el trabajo de los desarrolladores/mantenedores.

Si un fallo/característica no es parte de la responsabilidad de Arch, reportelo a los desarrolladores. Vea también #Razones por las que no es un fallo

¿Fallo o característica?

Fallo: Algo que debería funcionar pero no lo hace, de manera contraria a las intenciones del desarrollador.
Característica: Algo que un programa hace o haría si alguien lo programara.

Razones por las que no es un fallo

Porque es algo que le gustaría que hiciera un programa, y que no está implementado por los desarrolladores. En resumen: una nueva característica.
Porque el fallo ya fue reportado a los desarrolladores.
Porque el fallo que ya está arreglado en el código fuente pero no en Arch porque el paquete está desactualizado.
Porque es un paquete desactualizado. Use «Flag Package Out-of-Date» en pagina de los paquetes de Arch.
Porque el paquete que no usa los parches comunitarios de Fedora, Ubuntu, u otros. Los parches deben ser mandados a los desarrolladores.
Porque en el paquete la función no esencial X o la característica Y no están activadas. Esto es una petición de características.
Porque el paquete que no incluye un archivo .desktop o iconos' o alguna otra cosa de freedesktop. Esto no es una falla si esos archivos no están incluidos con el código fuente, y debe pedir a los desarrolladores que los incluyan. Si los desarrolladores proveen esos archivos pero estos no están en el paquete, entonces sí es un fallo.

Razones por las que no es una característica

Porque es un fallo...
Porque no es responsabilidad de Arch implementar la característica, es decir una característica nueva.
Porque el paquete no está actualizado. Use «Flag Package Out-of-Date» en pagina de los paquetes de Arch.
Porque el paquete que no usa los parches comunitarios de Fedora, Ubuntu, u otros. Los parches deben ser mandados a los desarrolladores.

Consiguiendo información útil

Aquí hay una lista de información útil que debería ser mencionada en su reporte:

La versión del paquete usada. Siempre especifique la versión del paquete. Poner «la ultima», «la lanzada hoy», o «el paquete en extra» no significa nada. Especialmente cuando el fallo no va ser arreglado justo ahora.
Las versiones de las librerías principales que usa el paquete (disponible en la variable «depends» en el PKGBUILD), cuando están relacionadas con el fallo. Si no sabe que información exactamente debe incluir, espere que alguien se la pida...
La versión del kernel que está usando si es que tiene problemas relacionados con el hardware.
Indique si la característica funciono en algún momento o no. Si eso paso, indique cuando dejó de funcionar.
Mencione la marca de su hardware si tiene problemas con el hardware.
Añada la información de registros relevantes si hay disponibles. Puede obtenerla en los siguientes lugares dependiendo de su problema:
- El systemd journal. Si usa syslog-ng, /var/log/messages debe contener registros relacionados al kernel y problemas con el hardware.
- ~/.local/share/xorg/Xorg.0.log, /var/log/Xorg.0.log, /var/log/Xorg.2.log o cualquier archivo de registro de Xorg si tiene problemas relacionados con el video (nvidia, ati, xorg...).
- Ejecute el programa en una consola y use algún modo debug (depuración) o verbose (verboso) si está disponible (vea la documentación del programa), y copie la salida en un archivo. Cuando ejecute la aplicación en la consola asegúrese que la información relevante esté en inglés para que mucha gente pueda entenderla. Puede hacer esto ejecutando export LC_ALL="C". Por ejemplo, si quiere conseguir información relevante sobre la ejecución de un programa llamado foobar, y el programa foobar tiene una opción --verbose:

$ export LC_ALL="C"
$ foobar --verbose

Esto solo va a afectar a la terminal actual y dejará de tener efecto cuando la cierre.

Si tiene que copiar mucho texto, como la salida de dmesg o un registro de Xorg, es preferible que lo guarde como un archivo y lo adjunte a su reporte de fallos. Es más preferible que adjunte un archivo a que use un pastebin para poner información relevante, ya que el contenido en un pastebin puede no estar disponible por un enlace expirado o algún otro problema posible. Al adjuntar un archivo se asegura que la información siempre esté disponible.

Indique como reproducir el fallo. Esto es muy importante, ya que puede ayudar a que más personas prueben el fallo y su solución en sus computadores.
Stack trace. Es una lista con las llamadas hechas por el programa durante su ejecución, va a ayudar a encontrar la parte del programa donde se encuentra el fallo, especialmente cuando por el error el programa se crashea. Puede obtener un stack trace usando gdb (El depurador de GNU) como se explica en Debug - Getting Traces#Getting the trace.

Abriendo un reporte de fallos

Cuando esté seguro si es un fallo o una característica y haya conseguido toda la información útil, entonces ya esta listo para reportar el fallo o pedir una característica.

Creando una cuenta

Tiene que crear una cuenta en el sistema de gestión de fallos de Arch. Esto es tan fácil como crear una cuenta en una wiki o en un foro y no hay nada en particular que mencionar sobre eso.

Proyectos

Cuando haya determinado si su característica o fallo está relacionado con Arch y no es un problema de los desarrolladores, tiene que reportarlo en el proyecto correcto. Seleccione el proyecto en el menú desplegable a la izquierda de el botón «Switch», en la esquina superior izquierda de la pagina de creación de reportes (no a la derecha de «Category»). Hay 5 proyectos:

Arch Linux – para paquetes en testing, core, o extra. También es donde está la documentación, sitios web (excepto el AUR), y problemas de seguridad.
AUR web interface – para los problemas con el código de la pagina del AUR y los servidores. Esto no incluye aplicaciones de terceras partes para acceder al AUR o a los paquetes en unsupported.
Community Packages – para los paquetes en community. Ahí no van los paquetes en unsupported.
Pacman – para pacman y los scripts y herramientas oficiales asociadas con el. Esto incluye cosas como makepkg y abs. No incluye los paquetes desarrollados por la comunidad como los ayudantes de AUR.
Release Engineering – hecho para todos los problemas relacionados con los lanzamientos (isos, instaladores, etc.).

No hay ningún lugar para reportar los problemas de los paquetes en unsupported. El AUR provee una forma de poner comentarios acerca de los paquetes en unsupported. Usted debe usarlo para reportar fallos al mantenedor del paquete.

Sumario

Escriba un sumario conciso y descriptivo.

Aquí tiene una lista de recomendaciones:

No ponga en el nombre «nombre del paquete esta roto después de la ultima actualización» – no es descriptivo, y «después de la ultima actualización» no tiene sentido en Arch.
Inicie el sumario con el nombre del paquete encerrado en corchetes , p.ej. «[nombre del paquete] 3.0.5-1 rompe la capacidad de copiar y pegar», así puede hacer el trabajo de los desarrolladores más fácil, ya que los reportes se pueden ordenar por el nombre del paquete.
No escriba demasiado en el sumario. El texto demás no será visible en la lista de reportes.

Severidades

Poniendo una severidad de critical no va a ayudar a resolver el fallo más rápido. Solo hará que los problemas que realmente son críticos sean menos visibles y hará que el desarrollador asignado a el fallo esté un poco menos dispuesto a arreglarlo.

Aquí hay formas de uso comunes para las severidades:

Critical (Critica) – Crasheo del sistema, fallos graves al inicio que probablemente vas a afectar a alguien ademas de usted, o un fallo de seguridad explotable en algún paquete del servicio central o que esté expuesto a la red.
High (Alta) – La funcionalidad principal de la aplicación no funciona, fallos de seguridad menos críticos, etc.
Medium (Media) – Alguna funcionalidad no esencial no funciona, no se respetan los estándares UNIX, etc.
Low (Baja) – Alguna funcionalidad opcional (un complemento o característica activada en la compilación) no funciona.
Very Low (Muy baja) – Un error en la documentación o traducción. Algo que no importa mucho pero debe ser tomado en cuenta en un lanzamiento futuro.

incluyendo información relevante

Esta puede ser la parte más difícil de reportar un fallo. Tiene que seleccionar la información que va a añadir a su reporte de la sección #Consiguiendo información útil. Esto depende de cual es el problema que enfrenta. Si no sabe que partes de la información son útiles, no sea tímido: es mejor dar más información de la necesaria a dar muy poca.

Puede encontrar un buen tutorial de como reportar fallos en [1].

Aunque puede que los desarrolladores o la gente encargada de los fallos le pidan más información si es necesario. Afortunadamente, después de algunos cuantos reportes, ya sabrá que información tiene que dar.

Puede poner la información más corta dentro del reporte, pero la información más larga (registros, capturas de pantalla...) debe ser adjuntada.

Siguiendo los reportes

¡No crea que porque ya reportó el fallo su trabajo está hecho!

Lo más probable es que los desarrolladores u otras personas le pidan más detalles y le den algunas posibles soluciones para que las pruebe. Si no responde de manera continua no se podrá cerrar el reporte, y el resultado final serán desarrolladores y usuarios enojados.

Votando y siguiendo

Usted puede votar por sus fallos favoritos. La cantidad de votos le indica a los desarrolladores cuanta gente esta siendo impactada por el problema. Pero, no es una manera muy buena de ayudar a que el fallo sea arreglado. Sería mucho más importante publicar cualquier información adicional que sepa acerca del fallo si es que no es el que lo reportó originalmente.

Seguir un reporte es importante – va a recibir un correo cada vez que añadan más comentarios o que el estatus del fallo cambie. Si abrió un reporte, verifique que la casilla «Notify me whenever this task changes» esté activada para recibir estos correos.

Respondiendo peticiones de información adicional

La gente se va a tomar el tiempo de leer su reporte e intentar ayudarlo. Usted debe continuar ayudándolos a resolver el fallo, si no responde sus preguntas, el fallo seguirá sin arreglarse y probablemente va a matar el entusiasmo por resolverlo.

Por favor, tómese el tiempo de dar más información si es que le piden, y pruebe las soluciones propuestas.

Los desarrolladores o los encargados de los fallos van a cerrar su reporte si no responde después de unas semanas o un mes.

Actualizando el reporte de fallos cuando una versión nueva del software es lanzada

Algunas veces, el fallo está relacionado a una versión especifica del software y es arreglado cuando lanzan una nueva. Si este es el caso, indíquelo en los comentarios del reporte y pida que lo cierren.

Cerrando el reporte cuando está solucionado

Puede pasar que la gente reporta un fallo pero no notifican cuando ya encontraron una solución, dejando al resto buscando una solución ya encontrada. Pida que cierren el reporte si encontró una solución y déjela en los comentarios.

Más acerca de los estatus de un fallo

Durante la vida de un fallo, este pasa por varios estados:

Unconfirmed (Sin confirmar) – Este es su estado por defecto. Acaba de ser reportado y nadie ha podido reproducirlo o confirmar que actualmente es un fallo.
New (Nuevo) – El fallo fue confirmado pero no ha sido asignado al desarrollador responsable de el software relacionado. Es usualmente el caso cuando una investigación es necesaria para determinar que software responsable por el fallo.
Assigned (Asignado) – El fallo ya fue asignado a el desarrollador responsable de el software involucrado en el fallo. No significa que ese desarrollador va a ser el que arregle el fallo. Ni siquiera significa que él va a trabajar en buscar la solución. Solo significa que el desarrollador va a encargarse del siclo de vida del fallo, incluyendo revisar lo parches si es que salen, soltando una solución y cerrando el reporte. No tiene sentido contactarse con los desarrolladores directamente para que arreglen el fallo más rápido, porque seguramente no les va a gustar...
Researching (Investigando) – Alguien está buscando una solución. Este estado es usado raramente en Arch, y es mejor así. El estado researching puede hacerle creer a la gente que no necesitan interesarse por el reporte. Pero usualmente se necesita más de una persona para resolver un fallo: Tener mucha gente experimentada arreglando un fallo ayuda mucho.
Waiting on Response (Esperando respuesta) y Requires testing (Requiere pruebas) – La persona que reportó el fallo debe proveer más información o tratar de proponer una solución, pero aún no responde. Esos estatus son usados raramente en Arch y deberían ser usados más. Pero es importante que usted siga el reporte (vea la sección #Votando y siguiendo) ya que los desarrolladores o la gente encargada de los fallos piden información en los comentarios.
A task closure has been requested (Se solicito una orden de cerrado) – Este no es un estatus exactamente, pero puede encontrar reportes con esta notificación. Esto indica que alguien ha solicitado que se cierre el reporte. Usualmente se añade una razón a la petición. Es cosa de el desarrollador asignado aceptar o no la solicitud.
Closed (Cerrado) – O no es un fallo valido (vea #Razones por las que no es un fallo) o ya se encontró y soltó una solución.

Algunas personas (desarrolladores, TUs...) son responsables de enviar los reportes y cambiar sus estatus.