Como presentar un Informe de Error

Foro para que la comunidad exprese sus opiniones, criticas, sugerencias y comentarios sobre los distintos servicios de la comunidad. Únicamente para discutir sobre el sitio de http://www.archlinux-es.org y sus partes.
Cerrado
Avatar de Usuario
madek
Equipo Hispano
Equipo Hispano
Mensajes: 2149
Registrado: 03 Sep 2009, 12:50
Ubicación: Puente Alto, Chile

Como presentar un Informe de Error

Mensaje por madek » 12 May 2011, 22:34

Aviso, esto no lo he creado yo, es una traduccion del blog de Allan McRae (si, el mismo que trata de estupidos a los usuarios :P )

He notado que hay algunas cosas que la gente podría mejorar al informar errores al gestor de fallos de Arch Linux. Así que aquí están algunas pautas de lo que personalmente me gusta ver en un informe de error. A raíz de estos haría encontrar y solucionar el fallo de trabajo menos para mí (y supongo que otros desarrolladores).

1. Compruebe el error no está informado: Esto incluye la comprobación del error informes cerrado recientemente, el problema puede estar ya fijada y en el proceso de propagación a los espejos. Esto evitará múltiples errores informes de la misma cuestión , que sólo crea más trabajo para todos los involucrados.

2. Proporcionar toda la información: En particular, no asuma que el error es evidente. Lo que podría parecer un error evidente que no se puede producir en el sistema de los desarrolladores, tan lleno de información sobre los paquetes involucrados e información detallada sobre la forma de reproducir el problema es fundamental. Siempre me gusta ver, como mínimo, la versión exacta del paquete que se trate (incluyendo pkgver y pkgrel) y la arquitectura del error que está ocurriendo en (i686 o x86_64). No sólo el informe es la "versión actual" de un paquete que puede ser inútil en pocos días en un comunicado de distribución móvil. La más específica que puede estar con el paquete de actualización en el tema comenzó a ocurrir, más fácil será para rastrear el cambio que la causó.

3. Stick a la información pertinente: La lista de 50 paquetes actualizados antes de darse cuenta de este error probable que contiene el paquete de problema, pero también hay una gran cantidad de actualizaciones no relacionadas. Reducir esta abajo tanto como sea posible antes de informar del problema. Más tiempo dedicado por un empaquetador de filtrado hasta sólo la información relevante en realidad significa menos tiempo corrigiendo errores.

4. No informar de los errores a través de enlaces: Proveer un enlace a un foro / hilo de la lista de correo que describe el error no es suficiente. Todavía es necesario para proporcionar un resumen detallado. Esto es para mantener toda la información en un solo lugar, sino que también evita que el error se pierde si el enlace se agota.

5. Un informe de error, un problema: Incluso si usted tiene problemas múltiples con un paquete, por lo general es mejor abrir un nuevo informe de errores para cada tema. Esto permite que cada error que se cierre, ya que es fijo (que no puede ser todo al mismo tiempo ...) y evita problemas de perderse entre los demás. La posible excepción a esto es que muchos pequeños problemas con un paquete se informó, junto con un PKGBUILD que fija a todos.

6. errores de las fuentes: Si un error es claramente un error del programa original y no un error de empaquetado, a continuación, tiene que ser informado en el bugtracker que corresponde. Está bien informar también la cuestión en el bug tracker de Arch (si se trata de un error y no una solicitud de función) con un enlace al informe del upstream por lo que el mantenedor del paquete puede seguir y aplicar la revisión cuando estén disponibles. Esto no sólo ahorra el empaquetador mucho tiempo (tienen muchos errores para tratar), pero también es útil para escuchar la información directamente de errores de la persona que lo experimenta. La excepción a esto es glibc que no aceptan los informes de errores de los usuarios ...

7. Seguimiento de cualquier duda: Esto es particularmente importante para los bugs que no pueden ser replicados por la relevancia del empaquetador. Cuanto más tiempo una pregunta sin respuesta se encuentra, más tiempo tomará para localizar y reparar su error. Si ya no se puede reproducir el problema debido a (por ejemplo) el cambio de hardware o de distribución, entonces nos dicen y se puede cerrar el informe de error.

8. No "yo también": Existe una función de votación sobre el informe de errores que puede utilizar para mostrar que también experimenta el problema. Anunciar "yo también" como un comentario sólo estorba el tracker.

Por último, recuerde que un error no existe hasta que está en el bug tracker. Comunicación de errores en las listas de correo, foros, IRC, Jabber, etc no cuenta. Estos son todos muy bien para detectar la fuente de su error antes de notificarlo, pero recuerda que los gestores de fallos existen por una razón.
Asi hacemos las cosas => The Arch Way
Judd Vinet "Arch Linux es lo que tú haces de él"
Imagen

Avatar de Usuario
sud_crow
Administrador
Administrador
Mensajes: 951
Registrado: 16 Abr 2005, 00:38
Ubicación: Buenos Aires - Argentina
Contactar:

Re: Como presentar un Informe de Error

Mensaje por sud_crow » 17 Dic 2011, 21:23

Esta es una guía sencilla para reportar errores, tanto en el sitio oficial, via el rastreador de bugs como aquí en el foro.
Se cierran los comentarios, ya que es a mero nivel informativo.
¿Revisaste la wiki? | ¿Usaste la función buscar del foro? | ¿Leíste las normas del foro?
Blog : | Correo+Jabber: leonardo @ archlinux-es.org

Cerrado