== Ubuntu Open Week - Trabajando con Bugs - Dante Díaz - Martes 3 de noviembre 2009 == {{{#!IRC [17:58:29] Hola a todos, en unos momentos iniciamos la charla sobre cómo trabajar con bugs [17:59:13] A continuación le damos lugar a viperhoot con su charla sobre trabajo con bugs [17:59:31] Permitanme primero presentarme, mi nombre es Dante Díaz (aka viperhoot) , miembro del equipo peruano de ubuntu (ubuntu-pe) [17:59:46] Es momento de comenzar [18:00:01] Como ya sabrán, muchos de los proyectos de software libre tienen una gran comunidad detrás [18:00:18] desde personas que apoyan en el desarrollo de aplicaciones como quienes las difunden con el boca a boca [18:00:30] Ubuntu y las aplicaciones que contiene no son la excepción :) [18:00:54] Gran parte del trabajo de mantener ubuntu se centra en Launchpad, una plataforma que aloja proyectos de software libre y facilita herramientas para colaboración y mejoramiento continuo de los proyectos allí alojados. [18:01:04] https://launchpad.net [18:01:27] En ubuntu, como otros proyectos que emplean launchpad se cuentan con equipos, que se encargan de diversas tareas [18:01:49] por ejemplo pueden colaborar con traducciones, ideas para nuevas versiones, corrección de errores, responder dudas, etc. [18:02:05] Nosotros en esta charla nos centraremos en el trabajo de corrección de errores (bugs). [18:02:29] En ubuntu hay un equipo que se encarga de trabajar constantemente contra los bugs, el Ubuntu BugSquad [18:02:35] https://launchpad.net/~bugsquad [18:03:04] La manera más sencilla de iniciarnos en el trabajo con bugs es por medio del "triaging" [18:03:34] consiste en clasificar aquellos errores que han sido ya reportados, adjuntarlos al paquete afectado, marcarlos por importancia, entre otras cosas. [18:03:57] Esta charla constará de dos partes: cómo hacer un buen reporte de error (bug report) y cómo clasificar errores de bugs ya reportados (triaging). [18:04:10] Primer tema: ¿Cómo hacer un buen reporte de bugs? [18:04:25] Digamos que estamos trabajando de lo más cómodo con nuestro sistema y de repente algo falla [18:04:40] no funciona como se espera, se trata muy probablemente de un fallo [18:05:09] si esperamos que sea solucionado (a la brevedad), lo mejor que podemos hacer es informalo para que algún desarrollador de este programa se ponga a trabajar en una solución. [18:05:19] Esto es hacer un reporte de error (bug report) [18:05:34] En Ubuntu reportar un bug es sencillo, pero se necesita de que el autor (la persona que reporta el error) brinde la mayor información posible. [18:05:50] El punto de partida para reportar un bug es esta página: https://bugs.launchpad.net/bugs/+filebug [18:06:04] allí, como indica, debemos de rellenar la información relacionada al bug [18:06:14] si afecta a una distribución (ubuntu) [18:06:26] un proyecto específico (digamos firefox por ejemplo) [18:06:39] y una breve descripción del error, a la que se puede adjuntar logs, .diff, etc [18:07:19] * Es importante que todo esto sea explicado en inglés, es el lenguaje con el que generalmente se trabaja en los reportes de errores y launchpad en general. atención con esta recomendación ;) [18:08:00] Existen algunas otras maneras más de reportar un bug, las vemos rápidamente [18:08:21] Dirigiéndonos directamente al menú "Ayuda" de alguna aplicación y escoger la opción "Informar de un problema" [18:08:46] esta opción hace el trabajo explicado anteriormente por nosotros [18:08:59] Pregunta: Para trabajar por ejemplo en una universidad se puede montar launchpad ? que tan complicado es [18:09:50] alucardni, podrías usar launchpad como plataforma para proyectos de software que tengas en un curso relacionado a una ingenieria de software [18:10:13] Tonny, launchpad es una plataforma bastante buena y compleja para la gestión de proyectos de software [18:10:40] te ofrece herramientas suficientes para encaminar tus proyectos, por lo que si, podrias usarla si es el caso de querer gestionar proyectos de software (libre) [18:11:10] volviendo al tema, nos dirigimos a "Ayuda"/"Informar de un problema" [18:11:21] esta opción hace el trabajo explicado anteriormente por nosotros [18:11:26] pregunta: miro que tambien podes reportar a debian, este reporte se envia al BTS de debian? [18:12:21] jimbodoors, no, en un primer momento todo se gestiona internamente por launchpad, launchpad se encarga de informar a las personas encargadas sobre este fallo [18:12:28] unicamente [18:12:53] puede pasar al BTS de Debian pero al ser bugs de muy alta prioridad [18:13:49] seguimos: "Informar de un problema", esta opción hace el trabajo explicado anteriormente por nosotros, es decir, recopila información de /var/crash e informa del proyecto (aplicación) afectado automaticamente [18:14:07] nosotros sólo tendremos que hacer una descripción del bug, [18:14:19] creo que es la manera más sencilla [18:14:46] Otra manera es abrir el terminal y escribir "ubuntu-bug nombre_programa", tendremos un resultado similar. [18:15:08] Unas muestras de cómo es un reporte de bug [18:15:15] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/266951 [18:15:27] Este es un bug "bien reportado" incluye bastante información útil para facilitar la detección del error. [18:15:50] Cuando hagamos un reporte de error hay que detallar toda la información posible acerca del mismo [18:16:06] por ejemplo con logs, pantallazos, describir los minutos previos y posterior al error, información adicional, todo lo posible [18:16:25] Aquel bug, parece ya haber sido corregido gracias al gran seguimiento que se pudo hacer al tener una buena información que ayudó a su investigación [18:16:38] Ahora veamos un ejemplo de un bug "mal reportado" [18:16:41] https://bugs.edge.launchpad.net/ubuntu/+bug/406072 [18:16:55] Notan diferencias? [18:17:08] Empezando por un título que no dice demasiado acerca de cual es el fallo. [18:17:45] la información que alli nos muestra son simplemente la lista de los dispositivos del pc, pero no hay información acerca del bug como tal [18:18:06] Este tipo de bugs terminan siendo cerrados por no poder hacer nada sin información para detectar el bug. [18:18:50] AHora les dictaré los pasos para empezar a hacer nuestro primer reporte de bugs, sólo recuerden no enviarlo al final, para no enviar un reporte inútil ;) [18:18:56] pregunta, no existe una guia para que la gente reporte bugs ?, en un proyecto que estoy esta subscrito a los bugs de launchpad, llegan todas las semanas 5 bugs repetidos, reportados por diferentes personas [18:19:21] rmayorga, existen varias de hecho, generalmente en inglés, pasaré unos enlaces al final con varias guías sobre este proceso vale? [18:19:47] A modo de ejemplo: Digamos que estamos navegando con Firefox y de un momento a otro el navegador se congela siempre que visitamos una página determinada. [18:20:13] Probablemente se trate de un error! Haremos un reporte de ejemplo [18:20:32] Para reportar el bug, nos dirigimos en Firefox al menú Ayuda/Informar de un problema [18:21:19] Se empezará generar un reporte con información sobre el sistema y el programa que ayude a los desarrolladores [18:21:38] Luego de ello el sistema nos preguntará si de verdad queremos enviar el reporte de error, pues claro :P [18:22:06] Nos dirigirá al sitio de launchpad, automaticamente ya se ha añadido los logs y la aplicación a la que hace mención el error [18:22:28] Ahora en el sitio de Launchpad, solamente necesitaremos añadir un resumen del fallo, sencillo. [18:22:47] Un resumen mas o menos decente puede ser como: "[karmic] mozilla firefox 3.5 se congela al cargar xxxx sitio" [18:23:04] es una buena práctica poner primeramente la versión de ubuntu a la que hacemos referencia [18:23:15] la versión de la aplicación y un titulo general del error (bug) [18:23:37] ahora, lógico que tiene que ser en inglés, por lo que quedaría algo como [karmic] mozilla firefox 3.5 freezes on accessing xxxx site [18:24:08] Dependiendo de si nuestro resumen se asemeja a algun otro bug reportado anteriormente, se nos mostrará una lista con bugs que pueden ser el que tratamos de reportar [18:24:28] si ese es el caso, es mejor escogerlo directamente, para evitar bugs duplicados. [18:24:39] Sino, reportamos directamente un nuevo bug. [18:25:11] Luego de esto seremos redirigidos a otra sección del sitio donde añadiremos información adicional sobre nuestro bug [18:25:29] Aqui podemos agregar, por ejemplo, la serie de pasos para reproducir el error [18:25:34] 1) Abrir mozilla firefox [18:25:49] 3) Ingresar al sitio web: algo.com [18:25:55] 4) Mostrar tal fallo [18:25:56] etc [18:26:03] Qué sucedió y qué esperabamos que sucediera. [18:26:15] y alguna otra descripción extra que podamos pensar que sea útil [18:26:25] (librerias en uso por ejemplo) [18:26:32] adjuntar pantallazos [18:26:33] etc [18:26:55] Y finalmente tendríamos que dar click en: Submit Bug Report (NO HACER CLICK YA QUE ESTAREMOS ENVIANDO UN BUG TOTALMENTE FICTICIO) [18:27:14] He creado un reporte a modo de demostración en base a este bug ficticio en: He creado un reporte a modo de demostración en base a este bug ficticio en [18:27:28] https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546 [18:28:07] como decía, es importante colocar los pasos para replicar el bug (disculpen si por descuido no lo incluí) :) [18:28:48] pero, por ejemplo, al reporte se le ha adjuntado información de mi versión de firefox, de la arquitectura de mi pc y una serie de datos que si en un principio no parecen entendibles, si que lo son y de gran utilidad para los encargados de revisar el bug [18:29:11] En esta página de bug veremos alguna información relacionada al error [18:29:34] dentro de los cuales se encuentran Status (Estado), Importancia, package (paquete o nombre del proyecto). [18:29:59] El estado nuevo (new) es el estado por defecto cuando se envia un reporte y pues... no es más que eso [18:30:07] Veremos que significa cada uno más adelante. [18:31:03] con eso abremos terminado de hacer nuestro primer reporte de bug, elaborado de acuerdo a lo que diriamos de buena manera, bien explicado, con detalles clave, claro, la idea es hacerlo con bugs reales no? [18:31:57] recuerden, inglés, utilizar el opción "Informar de un problema" de la mayoría de aplicaciones en ubuntu que es el camino más fácil y describirlo lo mejor posible [18:32:07] cualquier dato extra que piensen que pueda ser útil cuenta :) [18:32:47] Segundo tema : Triaging [18:33:07] Como verán en nuestro bug de ejemplo: https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546 [18:33:40] hay una serie de pequeños cuadros donde aparecen información como estado, importancia, asignado a, entre otrso [18:34:14] Triaging consiste en clasificar este y todos los bugs de acuerdo a estos criterios, es decir, paquete al que hace referencia y a los que afecta el error, estado, importancia... [18:34:41] Hay literalmente miles de errores reportados en Launchpad que necesitan ser clasificados para que puedan ser asignados al equipo correcto encargado de corregirlos. [18:35:15] Ya reportamos un bug, ahora el siguiente paso es su clasificación [18:35:42] Como dije al principio, el Bugsquad es un equipo que justamente se toma el trabajo de clasificar los errores reportados [18:36:09] así será más sencillo (y cómodo) para los desarrolladores el tratar de corregirlos [18:36:25] es mucho trabajo, a veces algo complicado, pero alguien tiene que hacerlo :P [18:36:42] Volviendo a nuestro reporte de error [18:36:45] https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546 [18:37:19] Veremos que en la sección Affects aparece "firefox-3.5 (Ubuntu)" , en Status: New, en Importance: Undecided, Assigned to: Unassignet [18:38:03] firefox-3.5 (Ubuntu) es el paquete al que hicimos referencia del error, se agregó de manera automatica al reportar el bug con la opción Ayuda/Informar de un problema de firefox [18:38:15] Los demás son los valores por defecto de cada bug recién reportado. [18:38:28] Para empezar con el triaging justamente tenemos que rellenar/modificar esta información lo más exacto posible en relación a cada bug. [18:38:51] Es un trabajo libre, es decir, cualquiera puede hacer ello, sólamente es necesario contar con una cuenta de launchpad, ganas de trabajar y cuidado con poner información correcta en estos cuadros [18:39:20] Para rellenar esta información sólo es necesario (una vez identificado en launchpad, los que no tienen cuenta en launchpad, es hora de ir creandola) ir a la página del reporte de error [18:39:36] y hacer click en la pequeña flecha que aparece debajo de la opción Affects, seguro que la ubicaron ;) [18:39:49] Verán que se desplegan diversas opciones [18:40:00] Daré una descripción de qué significa cada una [18:40:21] Package: el paquete al que hace referencia el error [18:40:27] en este caso es firefox-3.5 (ubuntu) [18:41:00] en cualquier otro tipo de bugs, el paquete no necesariamente aparecerá [18:41:12] por lo que tendremos que ubicarlo desde la opción "Choose..." [18:42:04] como decia s un poco complicado cuando no tenemos mucha información acerca de cual puede ser el paquete al que hace referencia el reporte de error [18:42:18] En esta página: [18:42:22] https://wiki.ubuntu.com/Bugs/FindRightPackage [18:42:51] en inglés (trataré de traducirla en lo que va de la semana a ver si se ayudan de ello ; ) ) [18:43:04] nos dan sugerencias de cual puede ser el paquete adecuado de acuerdo lo que dice el informe [18:43:25] Por ejemplo: si son fallos relacionados a firefox (como este caso) probablemente el paquete sea "firefox-3.5" [18:43:44] si son fallos relacionados a la impresora, seguramente el paquete sea "cups". Tienen toda una guia en ese enlace ;) [18:44:11] en nuestro caso del bug de demostración relacionado a firefox: el paquete es firefox-3.5 [18:44:37] En la sección Status (estado), la opción New (nuevo) es como ya dije, el estado de cada nuevo reporte [18:45:04] El incompleto (incomplete) generalmente se marca por alguien que adopta este reporte y requiere mas informacion que consultar a la persona [18:45:29] Confirmado (Confirmed) es bueno.. , cuando el reporte tiene la informacion suficiente y el bug es reproducible. [18:45:38] tambien existen otros estados [18:46:03] Fix commited (Se ha enviado la corrección del problema a los desarrolladores pero aun no se ha publicado en los repositorios) [18:46:24] Fix released: La solucion al problema se ha publicado oficialmente en los repositorios [18:46:43] Won't fixed: Esto es un poco controversial y significa que no puede ser reparado. [18:47:01] In progress: Se esta trabajando aun para solucionar este problema [18:47:25] hay un estado en particular que no se puede marcar ya que es necesario ser parte del equipo ubuntu bug control para setearlo y es el estado Triaged [18:48:01] La sección Importance (importancia) tampoco se puede modificar ya que es necesario pertenecer al equipo de ubuntu bug control para ello. [18:48:34] La opción Assigned to (Asignado a) Dependiendo de quien le hará el seguimiento al paquete (Nadie, Yo, o algun equipo, por ejemplo, kernel team, gnome team, etc) [18:48:57] Trabajaremos con el reporte ficticio sobre un error de Firefox al ver xxxx página [18:49:49] Ya estamos en la página del reporte de error, es hora de hacer triaging completando los datos, aquí cualquier de los assitentes puede hacer la modificación respectiva :P (click en la pestaña que aparece debajo de la opción affects) [18:50:12] No es necesario hacer ninguna modificación al paquete, puesto que ya está fijado con firefox-3.5 , sólo faltan cambios en los otros puntos [18:50:54] Para rellenar la sección estatus: Debemos de tomar en cuenta cómo se encuentra el reporte, aquí entra mucho en juego el sentido común y la práctica constante de trabajar clasificando bugs. [18:52:07] Por ejemplo nuestro reporte cuenta con muchos datos de referencia, y digamos que hemos replicado los pasos y tenemos el mismo error en nuestras pc's, en este caso eligiremos que el bug es real, cambiaremos la opción Estatus a Confirmed (confirmado) [18:52:47] Importance estará bloqueado por defecto, no podremos mover nada allí [18:52:56] Para rellenar la sección Assigned to: Crees poder trabajar en una solución a este error? [18:53:09] En este caso no será así, por lo que dejamos la opción en Nobody. [18:53:37] Si lo deseamos podemos dejar algún comentario acerca de las modificaciones hechas, en inglés de preferencia, aunque esto es totalmente opcional. [18:53:59] A veces habrán datos que no podamos terminar de llenar debido a falta de información, por ejemplo en firefox para una mejor clasificación del bug [18:54:18] podremos necesitar saber la versión de java o de flash instalada o la cantidad de extensiones extras instaladas [18:54:30] Un buen lugar para solicitar esta información al autor del reporte es en la sección de comentarios ;) [18:54:52] Hay una serie de respuestas predefinidas para diversas situaciones de los reportes, las pueden revisar aqui: https://wiki.ubuntu.com/Bugs/Responses [18:55:03] *Recuerden que deben estar escritas en inglés, así nos entendemos mejor todos ;) [18:55:26] Como última opción está la de marcar la casilla "mail me about changes to this bug report" si queremos estar atentos acerca de las modificaciones hechas a este reporte de error por parte de otros colaboradores [18:55:38] con mensajes informativos a nuestro buzón de correo. Una manera sencilla de hacerle seguimiento. [18:56:05] Guardamos nuestros cambios (Save Changes) y gracias a que hemos rellenado datos clave, ya hemos clasificado un bug! Ahora será más sencillo para los desarrolladores de aplicaciones ponerse a trabajar en los fallos. [18:56:31] reo que eso es todo para empezar con el trabajo de triaging. [18:56:52] Algunos enlaces que les pueden servir para reforzar esta breve charla [18:56:57] https://wiki.ubuntu.com/Jams/ES/Bugs [18:57:00] https://wiki.ubuntu.com/BugSquad/KnowledgeBase/ [18:57:03] https://wiki.ubuntu.com/Bugs/EasyTasks [18:57:07] https://wiki.ubuntu.com/Bugs/HowToTriage [18:57:17] Aquí finaliza la charla sobre cómo trabajar con bugs [18:57:23] Por mi parte gracias por su atención y ojalá les haya gustado ;) [18:57:31] Dudas en #ubuntu-centroamerica-chat [18:57:53] muchas gracias viperhoot [18:58:20] Un gusto, nos leemos en alguna otra ocasión ;) }}}