Bugs and feature requests/es

Bugzilla es la herramienta de rastreo utilizada por el Proyecto Fedora para obtener retroalimentación de usuarios y desarrolladores acerca de errores y peticiones para el mejoramiento de Fedora.

A veces, a los nuevos reportes les falta información, son imprecisos, o tienen otros defectos. Esto desperdicia tiempo valioso, tanto a la persona que lo reportó sin la precisión necesaria, como el desarrollador que pierde tiempo con el error mal documentado, lo que podría incluso resultar en que el error sea ignorado u olvidado. Esta página describe como archivar reportes de error de calidad y sugerir mejoras de una forma constructiva.

¿Necesito archivar un reporte de error?
A menos que encuentre un problema ya reportado en Bugzilla, mencionado en las notas de lanzamiento u otra documentación oficial (lea http://docs.fedoraproject.org/), reconocido por los desarrolladores en una lista de correo, listado en la página de errores comunes, o listado como una dependencia rota en el reporte diario de Rawhide, usted debería archivar un error. No asuma que todo mundo ha encontrado el mismo problema que usted; muchos errores son específicos a un hardware en particular, configuración, o hábitos de uso. Discutir el error en IRS o en la lista de correo fedora-test-list puede ayudarle a diagnosticar la fuente exacta y coordinar con otros experimentando el mismo problema, pero no es una vía idónea para reportar el error. Debería ser reportado en Bugzilla para que al asunto se le de el seguimiento apropiado y no se pierda entre todo el ruido de la lista de correos.

Una práctica común es archivar un error primero, entonces enviar un correo a la lista con un enlace al reporte de error, solicitando mayor asistencia. Muchos errores son también archivos sin enviar correos a la lista, así que asegúrese de hacer una búsqueda en Bugzilla respecto a su problema.

El flujo de trabajo en Bugzilla
Una visión general del flujo de trabajo para errores de Fedora puede encontrarse aquí. Esto debería ayudarle a entender el ciclo de vida de un error.

Manos a la obra
Si usted es nuevo en el Bugzilla de Fedora, entonces el primer paso es crear una cuenta. Es un proceso rápido, así que no tema comenzar justo ahora mismo. Para detalles acerca del proceso de creación de su cuenta, por favor consulte la documentación de bugzilla.

Comprendiendo la cultura de Bugzilla
Entender como otras personas esperan que usted use el sistema mejorará la manera en que su problema es mostrado, hará a otros más receptivos y más dispuestos a corregir su error, y hará la experiencia más placentera para todos. Si usted nunca ha utilizado Bugzilla antes o es nuevo llenando reportes de error, puede serle útil leer las siguientes páginas.


 * General Bugzilla Etiquette
 * bugzilla.redhat.com pointers - describes the essential steps to follow for all bugs!
 * How to Report Bugs Effectively (general advice)

Si un software en particular es de uso común, es más probable que los usuarios encuentren problemas y/o sugieran mejoras al mismo. No significa que el software es más defectuoso.

BugZappers/UnderstandingBugzilla tiene unas cuantas notas técnicas que podrían ayudar a que Bugzilla cobre más sentido para usted.

Buscando Duplicados
Errores muy comunes se listan en Bugs/Common.

Es importantes buscar en Bugzilla para asegurarse de que su error no ha sido ya reportado. La manera más fácil de hacerlo es keyword search, o puede utilizar la Búsqueda Avanzada. O bien, utilice https://bugz.fedoraproject.org/nombredelpaquete para buscar errores específicos para el paquete (subtituyendo nombredelpaquete con el nombre del paquete que está verificando).

No es de utilidad generalmente archivar comentarios como "Estoy experimentando este error, también yo", a menos que ahí haya detalles específicos que pudiesen ser útiles en rastrear la causa (p.ej. usted tiene más detallada información de depuración, o un diferente hardware o configuración de software que significa que un error específico de hardware o de configuración es más extendido de lo que se pensaba previamente).

Si usted está experimentando el error en una más reciente versión de Fedora que la reportada en el error, esto es útil de mencionar.

Lea BugZappers/FindingDuplicates para mayores detalles.

Reuniendo Información Útil
Lea "Tips por tipo de error" debajo para guía específica.

Es siempre útil observar /var/log/messages (en todos los casos) y ~/.xsession-errors (para usuarios de escritorio) y mirar si hay algún error o advertencia relacionado a su problema. Algunos programas tienen también archivos dedicados o directorios en /var/log que es mejor verificar.

Comience a archivar el error
Usted puede ingresar el error aquí, o si conoce el nombre del paquete puede ir a https://bugz.fedoraproject.org/nombredelpaquete (subtituyendo nombredelpaquete con el nombre del paquete que está verificando) y seguir el enlace 'Report a new bug against this package'.

Lea la plantilla de informe cuidadosamente y proporcione la información requerida, lo mejor que pueda.

Por favor intente explicar claramente el error y toda la información necesaria. No es una buena idea añadir comentarios como "¡esto necesita ser corregido inmediatamente!" o "¡esto es inaceptable!"; probablemente sólo hará que los mantenedores sientan que los está atacando, y esto no les ayudará a corregir el problema.

Encontrando el Componente exacto
Cuando reporte un error, será de gran ayuda si selecciona el Productor correcto, Version y Componentes. De esta manera, llegará al desarrollador/mantenedor del paquete de software afectado, lo que ayudará a resolver los errores más rápido. Si usted lo asigna al componente erróneo, puede ser reasignado al correcto, así que nunca evite llenar el reporte de error sólo porque usted no logra imaginarse a que componente asignarlo.

Lea BugZappers/CorrectComponent para detalles acerca de como determinar el componente correcto si no está seguro.

Después de archivar su error

 * Los desarrolladores no dan acuse de recibo por reportes de error u ofrecen comentarios a menos que tengan información substancial o requieran más información de parte suya. Eso no significa que sus reportes de error no sean valiosos. ¡Que sigan llegando!


 * Después de reportar un error, podría obtener retroalimentación de otros usuarios, o el desarrollador podría cambiar el status y/o resolución del reporte de error. Para una explicación de los varios status y resoluciones, lea this page.


 * Por favor mantenga su reporte enfocado en el asunto original que fue reportado. Añadir discusiones de otros ligeramente relacionados (o por completo sin relación alguna) solo causará que el reporte se vuelva confuso y difícil de seguir. Si advierte un problema diferente, o cuando el problema inicial sea corregido usted advierte de otro problema que el que está escondiendo, por favor archive un nuevo reporte en lugar de agregar comentarios al primer informe.


 * Si usted archiva un error contra una versión de Fedora que no está corregido o de otra manera resuelto antes de que la versión alcance el final de su ciclo de vida (EOL), alguien necesitará probar una versión más reciente de Fedora para verificar si el error persiste y actualizar el campo de Versión si es el caso. De otro modo, su error será cerrado. Obtendrá un e-mail de verificación entonces. Muchos errores son corregidos o se vuelven obsoletos cuando el software es incorporado en nuevas versiones de Fedora por los programadores principales. Errores más antigos permanecen en el sistema para referencias futuras, pero volver a probar mantendrá el error abierto y "en el radar" para desarrolladores de Fedora. Lea BugZappers/HouseKeeping para mayor información sobre el proceso.

Interfaz de línea de comandos
Si necesita una línea de comandos u otra interfaz programable para Bugzilla, intente con "yum install python-bugzilla" y lea la documentación incluida. Esto proporciona el comando "bugzilla".

Lo que cada error debería tener

 * Número de Versión: El número exacto de versión del RPM del problema (o una lista de RPMs sospechosos). El número en el campo de selección Versión es la versión de Fedora como un todo (12,13, Rawhide); el número de versión RPM para un componente específico dentro de la distribución cambiará conforme se vayan liberando actualizaciones.


 * Descripción clara: Reportar tanto como sea posible acerca de que estaba ocurriendo en el momento del incidente, o los pasos exactos para reproducir el error. Explicación de como lo que ocurrió difiere de lo que debería haber ocurrido, si no es obvio.


 * Información de Diagnóstico: Cualquier advertencia relevante impresa en pantalla, extractos de registros del sistema (logs) cerca de la hora del error, cualquier volcado disponible que ayude a detectar el error.


 * Contexto: Por ejemplo, si este es un problema del administrador de ventanas, o ¡está ocurriendo bajo GNOME o KDE? Si este es un problema de red, ¿cómo está la configuración de la red?Si una aplicación estaba corriendo de una manera inusual (emulation, en forma remota), esto debería mencionarse. ¿Qué elementos relacionados en el sistema han sido personalizados? Use su buen juicio y sentido común.

Información adicional puede ser solicitada adicionalmente, dependiendo del tipo de error y componente afectado. Lea "Tips por tipo de error" debajo.