openSUSE:Preguntas frecuentes sobre el envío de informes de error

Errores

Envío de informes de error - Preguntas frecuentes sobre el envío de mensajes de error - Pruebas

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 décadas darnos cuenta leyendo los logs. Tu tienes esa información fácilmente disponible, así que 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.

Así que debería 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 vagancia. Hacerlo correctamente te quita tiempo una sola vez, pero todos los que están 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 últimos comentarios hechos, la pregunta o el requisito que se solicito acerca de que información adicional debería 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.

Nuestros responsables reciben muchos correos generados en picos de trabajo (como durante la fase Beta) no pueden reaccionar razonablemente a cada uno individualmente, así que en un momento concreto tengan que usar como último recursos las listas de los status de los fallos - y entonces hay muchas posibilidades de que sea pasado por alto que alguna información pedida esté disponible ahora y el trabajo en el fallo se pueda continuar.

Así que, es el interés de cada persona que informa de fallos el cambiar el status del fallo de NEEDINFO a otro, después de que se respondan a las preguntas.

Por supuesto, a veces puedes tener suerte y el dueño del fallo se puede dar cuenta de que la información pedida está disponible ahora y cambia el status del fallo a ASSIGNED él mismo, pero confiar en la buena suerte no es normalmente una buena táctica.

Por favor, ten en cuenta de que hay fallos asignados a BNC-Screening-Team (principalmente problemas relacianados con YaST y X11) inicialmente o durante el proceso no deberían cambiarse de NEEDINFO a ASSIGNED por quien informó del fallo o por la persona que pidieron información. El motivo es que un cambio de status casi siempre significa que haya una reasignación, que este equipo hace. Cambiar el status podría causar al fallo específico aparecer en el listado incorrecto y podría por lo tanto no ser tratado de forma eficiente (reasignado). Gracias por tener esto en cuenta.