Bug Reporting FAQ

De openSUSE, la enciclopedia libre.

Bugzilla

Gestión General de Errores

Este documento explica como usar: bugzilla at bugzilla.novell.com.

¿Qué campos deberían ser rellenados inicialmente? ¿Qué campos debería cambiar y cuales no?

• Componente
  Nota: No todos los fallos (bugs) durante la instalación son culpa de YaST, podrían ser, por ejemplo, problemas del Kernel.
• Plataforma
  Utilize "all" (todas) si piensa que el fallo ocurre en todas las plataformas, si no seleccione una plataforma específica.
• Resumen
  Recuerde que las personas que lean el resumen deberían entender que es lo que sucede.
• Descripción del Problema
  Escriba todos los detalles que pueda acerca del fallo. Recuerde que no debería escribir "Vea el Resumen", ya que el mismo puede cambiar.
• ¿Cómo reproducirlo?
  Este campo es tan importante que merece una explicación adicional en P: 1.1.5
• Gravedad
  Seleccione el nivel correcto de gravedad. Seleccione el fallo como "Blocker" (bloqueador) si piensas que el producto no debería ser distribuido mientras este fallo no sea corregido.
• Campos restantes
  No necesitas rellenar ninguno de los demás campos, ya que los valores por defecto están bien.

¿Recibiré algún mensaje de vuelta después de informar sobre un fallo?

Sí, si sus "preferencias" no han cambiado, recibirá un correo electrónico cuando se produzca alguna modificación.

¿Qué campos debería cambiar y cuales no?

Al no ser un desarrollador, como regla general solo deberías añadir comentarios adicionales, o añadirse al CC. Si el fallo esta en el estado de "NEEDINFO" (NECESITAINFO) recuerde ponerlo en el estado "ASSIGNED" (ASIGNADO) después de dar toda la información.

¿Qué debería hacer si la versión actual de SUSE Linux tiene el mismo (o semejante) problema que ya existe pero se informó de él en una versión anterior?

Sugiero mover la versión del paquete y escribir algo como "Se informó de este fallo en SUSE Linux x.y y todavía existe en SUSE Linux u.v. Estoy ajustando la versión". Si el fallo se cerró anteriormente, deberías reabrirlo.

La gente se enfada conmigo por que puse "Instalación de SUSE x.y-Beta-z" en el campo "how to reproduce" en Bugzilla. ¿Por qué?

Simplemente porque la información no es muy útil - redundante y no ayuda de ninguna manera a reproducir o replicar el problema. Podemos decir que el problema es de la instalación por que seleccionaste "Installation" en la lista de componentes de Bugzilla, y podemos decir que versión instalastes gracias a la lista de versiones que está a la derecha de la lista de componentes.

Lo que realmente necesitamos saber es que hiciste y cómo lo hiciste - Descripciones como " Inicie desde el CD1, seleccioné "Instalación", seleccioné el idioma "Klingon", deje las demás opciones como estaban, confirmé la instalación, mira como mi disco duro se inflama."

Y no, no somos quisquillosos - existen tantos modos de instalación, y tantos maneras de instalarlo que nos llevaría decadas darnos cuenta leyendo los logs. Tu tienes esa información fácilmente disponible, asique por favor, ponlo en el campo correspondiente.

Claro que no necesitamos ese nivel de detalle cuando informas sobre un fallo del texto de ayuda en uno de los diálogos finales de la configuración de hardware (como el de la impresora, la tarjeta capturadora de televisión, etc.) - pero los pasos que tomastes para llegar al lugar donde el problema surgió es lo que realmente necesitamos. Tenemos tantas cajas de diálogo que no es fácil darse cuenta de lo que quieres decir o de que manera lo hiciste.

La gente no estaba muy contenta porque sólo escribí "lee el título" en la descripción del fallo de Bugzilla - pero mi título realmente lo explica todo! ¿No es pura quisquillosidad insistir que los informadores de fallos repitan eso en el campo de descripción?

No, de ninguna manera.

Los títulos cambian todo el tiempo. El problema del que tu informas puede ser sólo la punta del iceberg - el verdadero problema podría estar en un lugar totalmente diferente, y entonces aquellos que sepan el lugar, pues cambiarían el título de manera acorde. Esto significa que el título original se perdería.

Asique deberia ser suficientemente obvio que el campo del título no es el lugar para guardar información relevante, y que el problema en si es la única información más importante en un informe de fallos.

Es también simplemente un mal estilo poner toda clase de información en el título del problema, y luego hacer referencia sólo al título. Esto es simplemente pura vaguería. Hacerlo correctamente te quita tiempo una sola vez, pero todos los que estan trabajando en el problema tienen que buscar la información por todos los sitios una y otra vez.

Además de ésto, un título debe ser conciso - pero la descripción de un fallo debe ser aclaratoria. Ambos requisitos son contradictorios.

Estado del Problema NEEDINFO

¿Qué significa el estado NEEDINFO, Cómo debe ser gestionado?

NEEDINFO significa que el dueño del fallo (La persona que está trabajando para resolverlo) necesita más información acerca del mismo - Normalmente esta información debería venir de quien informo sobre el fallo.

Si consigues que un fallo del que informaste este colocado en el estado NEEDINFO, ubique, en los ultimos comentarios hechos, la pregunta o el requisito que se solicito acerca de que informacion adicional deberia suplir (como logs).

Si este es el caso, por favor responda la pregunta hecha o proporcione la informacion solicitada, y modifique el estado del fallo a ASSIGNED - Presione en Aceptar el fallo (cambiar estado a asignado) [ASSIGNED - click on Accept bug (change status to ASSIGNED)] en la página de detalles sobre el fallo en Bugzilla.

No me convierto en el dueño del fallo cuando cambio el status de NEEDINFO a ASSIGNED - dando a Aceptar el fallo (cambiar estado a asignado) [ASSIGNED - click on Accept bug (change status to ASSIGNED)] en la página de detalles del fallo en Bugzilla?

No, El dueño del fallo seguirá igual, solo el status cambiará. Puede realizar este cambio sin el temor de que como consecuencia el fallo se vuelva a ser de su responsabilidad.

¿Por qué es importante cambiar el status de un fallo de NEEDINFO a ASSIGNED? ¿A caso eso no es responsabilidad del dueño del fallo?

No, esto es la responsabilidad de quien responda a lo que le preguntaron o de quien proporciona la información que se le pidió.

Los dueños de los fallos usan NEEDINFO para que así puedan ver de forma más fácil en que fallos realmente pueden trabajar (aquellos puestos en ASSIGNED, NEW, o REOPENED) y cuales están atrancados porque es importante la información que falta - NEEDINFO fallos que ya no aparecen en su lista to-do (por hacer) de fallos abiertos (open bugs).

Por eso es importante que el status del fallo se cambie de NEEDINFO a otro status - el dueño del fallo podría pasar por alto el correo que Bugzilla envía automaticamente cuando se añade un comentario al fallo, y entonces este fallo podría permanecer en el status NEEDINFO por un periodo de tiempo indefinido.

Our maintainers receive so many generated mails that at peak times (like during a Beta phase) they cannot reasonably react to each one individually, so at a certain point they have to resort to bug status lists - and then chances are that it is overlooked that some requested information is now available and work on a bug can resume.

So it is in the own interest of each bug reporter to change the bug status away from NEEDINFO after the questions are answered.

Of course, sometimes you can be lucky and the bug owner realizes that the requested information is now available and sets the bug status to ASSIGNED himself, but relying on luck is usually not a good tactic.

Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-realted problems) initially or during the process should not be set from NEEDINFO to ASSIGNED by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account.