Ubuntu Wiki

   1 [17:58:29] <viperhoot>  Hola a todos, en unos momentos iniciamos la charla sobre cómo trabajar con bugs
   2 [17:59:13] <alucardni>  A continuación le damos lugar a viperhoot con su charla sobre trabajo con bugs
   3 [17:59:31] <viperhoot>  Permitanme primero presentarme, mi nombre es Dante Díaz (aka viperhoot) , miembro del equipo peruano de ubuntu (ubuntu-pe)
   4 [17:59:46] <viperhoot>  Es momento de comenzar
   5 [18:00:01] <viperhoot>  Como ya sabrán, muchos de los proyectos de software libre tienen una gran comunidad detrás
   6 [18:00:18] <viperhoot>  desde personas que apoyan en el desarrollo de aplicaciones como quienes las difunden con el boca a boca
   7 [18:00:30] <viperhoot>  Ubuntu y las aplicaciones que contiene no son la excepción :)
   8 [18:00:54] <viperhoot>  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.
   9 [18:01:04] <viperhoot>  https://launchpad.net
  10 [18:01:27] <viperhoot>  En ubuntu, como otros proyectos que emplean launchpad se cuentan con equipos, que se encargan de diversas tareas
  11 [18:01:49] <viperhoot>  por ejemplo pueden colaborar con traducciones, ideas para nuevas versiones, corrección de errores, responder dudas, etc.
  12 [18:02:05] <viperhoot>  Nosotros en esta charla nos centraremos en el trabajo de corrección de errores (bugs).
  13 [18:02:29] <viperhoot>  En ubuntu hay un equipo que se encarga de trabajar constantemente contra los bugs, el Ubuntu BugSquad
  14 [18:02:35] <viperhoot>  https://launchpad.net/~bugsquad
  15 [18:03:04] <viperhoot>  La manera más sencilla de iniciarnos en el trabajo con bugs es por medio del "triaging"
  16 [18:03:34] <viperhoot>  consiste en clasificar aquellos errores que han sido ya reportados, adjuntarlos al paquete afectado, marcarlos por importancia, entre otras cosas.
  17 [18:03:57] <viperhoot>  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 [18:04:10] <viperhoot>  Primer tema: ¿Cómo hacer un buen reporte de bugs?
  19 [18:04:25] <viperhoot>  Digamos que estamos trabajando de lo más cómodo con nuestro sistema y de repente algo falla
  20 [18:04:40] <viperhoot>  no funciona como se espera, se trata muy probablemente de un fallo
  21 [18:05:09] <viperhoot>  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.
  22 [18:05:19] <viperhoot>  Esto es hacer un reporte de error (bug report)
  23 [18:05:34] <viperhoot>  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.
  24 [18:05:50] <viperhoot>  El punto de partida para reportar un bug es esta página: https://bugs.launchpad.net/bugs/+filebug
  25 [18:06:04] <viperhoot>  allí, como indica, debemos de rellenar la información relacionada al bug
  26 [18:06:14] <viperhoot>  si afecta a una distribución (ubuntu)
  27 [18:06:26] <viperhoot>  un proyecto específico (digamos firefox por ejemplo)
  28 [18:06:39] <viperhoot>  y una breve descripción del error, a la que se puede adjuntar logs, .diff, etc
  29 [18:07:19] <viperhoot>  * 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 ;)
  30 [18:08:00] <viperhoot>  Existen algunas otras maneras más de reportar un bug, las vemos rápidamente
  31 [18:08:21] <viperhoot>  Dirigiéndonos directamente al menú "Ayuda" de alguna aplicación y escoger la opción "Informar de un problema"
  32 [18:08:46] <viperhoot>  esta opción hace el trabajo explicado anteriormente por nosotros
  33 [18:08:59] <alucardni>  <Tonny> Pregunta: Para trabajar por ejemplo en una universidad se puede montar launchpad ? que tan complicado es
  34 [18:09:50] <viperhoot>  alucardni, podrías usar launchpad como plataforma para proyectos de software que tengas en un curso relacionado a una ingenieria de software
  35 [18:10:13] <viperhoot>  Tonny, launchpad es una plataforma bastante buena y compleja para la gestión de proyectos de software
  36 [18:10:40] <viperhoot>  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)
  37 [18:11:10] <viperhoot>  volviendo al tema, nos dirigimos a "Ayuda"/"Informar de un problema"
  38 [18:11:21] <viperhoot>  esta opción hace el trabajo explicado anteriormente por nosotros
  39 [18:11:26] <alucardni>  <jimbodoors> pregunta: miro que tambien podes reportar a debian, este reporte se envia al BTS de debian?
  40 [18:12:21] <viperhoot>  jimbodoors, no, en un primer momento todo se gestiona internamente por launchpad, launchpad se encarga de informar a las personas encargadas sobre este fallo
  41 [18:12:28] <viperhoot>  unicamente
  42 [18:12:53] <viperhoot>  puede pasar al BTS de Debian pero al ser bugs de muy alta prioridad
  43 [18:13:49] <viperhoot>  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
  44 [18:14:07] <viperhoot>  nosotros sólo tendremos que hacer una descripción del bug,
  45 [18:14:19] <viperhoot>  creo que es la manera más sencilla
  46 [18:14:46] <viperhoot>  Otra manera es abrir el terminal y escribir "ubuntu-bug nombre_programa", tendremos un resultado similar.
  47 [18:15:08] <viperhoot>  Unas muestras de cómo es un reporte de bug
  48 [18:15:15] <viperhoot>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/266951
  49 [18:15:27] <viperhoot>  Este es un bug "bien reportado" incluye bastante información útil para facilitar la detección del error.
  50 [18:15:50] <viperhoot>  Cuando hagamos un reporte de error hay que detallar toda la información posible acerca del mismo
  51 [18:16:06] <viperhoot>  por ejemplo con logs, pantallazos, describir los minutos previos y posterior al error, información adicional, todo lo posible
  52 [18:16:25] <viperhoot>  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
  53 [18:16:38] <viperhoot>  Ahora veamos un ejemplo de un bug "mal reportado"
  54 [18:16:41] <viperhoot>  https://bugs.edge.launchpad.net/ubuntu/+bug/406072
  55 [18:16:55] <viperhoot>  Notan diferencias?
  56 [18:17:08] <viperhoot>  Empezando por un título que no dice demasiado acerca de cual es el fallo.
  57 [18:17:45] <viperhoot>  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
  58 [18:18:06] <viperhoot>  Este tipo de bugs terminan siendo cerrados por no poder hacer nada sin información para detectar el bug.
  59 [18:18:50] <viperhoot>  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 ;)
  60 [18:18:56] <alucardni>  <rmayorga> 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
  61 [18:19:21] <viperhoot>  rmayorga, existen varias de hecho, generalmente en inglés, pasaré unos enlaces al final con varias guías sobre este proceso vale?
  62 [18:19:47] <viperhoot>  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.
  63 [18:20:13] <viperhoot>  Probablemente se trate de un error! Haremos un reporte de ejemplo
  64 [18:20:32] <viperhoot>  Para reportar el bug, nos dirigimos en Firefox al menú Ayuda/Informar de un problema
  65 [18:21:19] <viperhoot>  Se empezará generar un reporte con información sobre el sistema y el programa que ayude a los desarrolladores
  66 [18:21:38] <viperhoot>  Luego de ello el sistema nos preguntará si de verdad queremos enviar el reporte de error, pues claro :P
  67 [18:22:06] <viperhoot>  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
  68 [18:22:28] <viperhoot>  Ahora en el sitio de Launchpad, solamente necesitaremos añadir un resumen del fallo, sencillo.
  69 [18:22:47] <viperhoot>  Un resumen mas o menos decente puede ser como: "[karmic] mozilla firefox 3.5 se congela al cargar xxxx sitio"
  70 [18:23:04] <viperhoot>  es una buena práctica poner primeramente la versión de ubuntu a la que hacemos referencia
  71 [18:23:15] <viperhoot>  la versión de la aplicación y un titulo general del error (bug)
  72 [18:23:37] <viperhoot>  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
  73 [18:24:08] <viperhoot>  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
  74 [18:24:28] <viperhoot>  si ese es el caso, es mejor escogerlo directamente, para evitar bugs duplicados.
  75 [18:24:39] <viperhoot>  Sino, reportamos directamente un nuevo bug.
  76 [18:25:11] <viperhoot>  Luego de esto seremos redirigidos a otra sección del sitio donde añadiremos información adicional sobre nuestro bug
  77 [18:25:29] <viperhoot>  Aqui podemos agregar, por ejemplo, la serie de pasos para reproducir el error
  78 [18:25:34] <viperhoot>  1) Abrir mozilla firefox
  79 [18:25:49] <viperhoot>  3) Ingresar al sitio web: algo.com
  80 [18:25:55] <viperhoot>  4) Mostrar tal fallo
  81 [18:25:56] <viperhoot>  etc
  82 [18:26:03] <viperhoot>  Qué sucedió y qué esperabamos que sucediera.
  83 [18:26:15] <viperhoot>  y alguna otra descripción extra que podamos pensar que sea útil
  84 [18:26:25] <viperhoot>  (librerias en uso por ejemplo)
  85 [18:26:32] <viperhoot>  adjuntar pantallazos
  86 [18:26:33] <viperhoot>  etc
  87 [18:26:55] <viperhoot>  Y finalmente tendríamos que dar click en: Submit Bug Report (NO HACER CLICK YA QUE ESTAREMOS ENVIANDO UN BUG TOTALMENTE FICTICIO)
  88 [18:27:14] <viperhoot>  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
  89 [18:27:28] <viperhoot>  https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546
  90 [18:28:07] <viperhoot>  como decía, es importante colocar los pasos para replicar el bug (disculpen si por descuido no lo incluí) :)
  91 [18:28:48] <viperhoot>  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
  92 [18:29:11] <viperhoot>  En esta página de bug veremos alguna información relacionada al error
  93 [18:29:34] <viperhoot>  dentro de los cuales se encuentran Status (Estado),  Importancia, package (paquete o nombre del proyecto).
  94 [18:29:59] <viperhoot>  El estado nuevo (new) es el estado por defecto cuando se envia un reporte y pues... no es más que eso
  95 [18:30:07] <viperhoot>  Veremos que significa cada uno más adelante.
  96 [18:31:03] <viperhoot>  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?
  97 [18:31:57] <viperhoot>  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
  98 [18:32:07] <viperhoot>  cualquier dato extra que piensen que pueda ser útil cuenta :)
  99 [18:32:47] <viperhoot>  Segundo tema : Triaging
 100 [18:33:07] <viperhoot>  Como verán en nuestro bug de ejemplo: https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546
 101 [18:33:40] <viperhoot>  hay una serie de pequeños cuadros donde aparecen información como estado, importancia, asignado a, entre otrso
 102 [18:34:14] <viperhoot>  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...
 103 [18:34:41] <viperhoot>  Hay literalmente miles de errores reportados en Launchpad que necesitan ser clasificados para que puedan ser asignados al equipo correcto encargado de corregirlos.
 104 [18:35:15] <viperhoot>  Ya reportamos un bug, ahora el siguiente paso es su clasificación
 105 [18:35:42] <viperhoot>  Como dije al principio, el Bugsquad es un equipo que justamente se toma el trabajo de clasificar los errores reportados
 106 [18:36:09] <viperhoot>  así será más sencillo (y cómodo) para los desarrolladores el tratar de corregirlos
 107 [18:36:25] <viperhoot>  es mucho trabajo, a veces algo complicado, pero alguien tiene que hacerlo :P
 108 [18:36:42] <viperhoot>  Volviendo a nuestro reporte de error
 109 [18:36:45] <viperhoot>  https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/473546
 110 [18:37:19] <viperhoot>  Veremos que en la sección Affects aparece "firefox-3.5 (Ubuntu)" , en Status: New, en Importance: Undecided, Assigned to: Unassignet
 111 [18:38:03] <viperhoot>  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
 112 [18:38:15] <viperhoot>  Los demás son los valores por defecto de cada bug recién reportado.
 113 [18:38:28] <viperhoot>  Para empezar con el triaging justamente tenemos que rellenar/modificar esta información lo más exacto posible en relación a cada bug.
 114 [18:38:51] <viperhoot>  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
 115 [18:39:20] <viperhoot>  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
 116 [18:39:36] <viperhoot>  y hacer click en la pequeña flecha que aparece debajo de la opción Affects, seguro que la ubicaron ;)
 117 [18:39:49] <viperhoot>  Verán que se desplegan diversas opciones
 118 [18:40:00] <viperhoot>  Daré una descripción de qué significa cada una
 119 [18:40:21] <viperhoot>  Package: el paquete al que hace referencia el error
 120 [18:40:27] <viperhoot>  en este caso es firefox-3.5 (ubuntu)
 121 [18:41:00] <viperhoot>  en cualquier otro tipo de bugs, el paquete no necesariamente aparecerá
 122 [18:41:12] <viperhoot>  por lo que tendremos que ubicarlo desde la opción "Choose..."
 123 [18:42:04] <viperhoot>  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
 124 [18:42:18] <viperhoot>  En esta página:
 125 [18:42:22] <viperhoot>  https://wiki.ubuntu.com/Bugs/FindRightPackage
 126 [18:42:51] <viperhoot>  en inglés (trataré de traducirla en lo que va de la semana a ver si se ayudan de ello ; ) )
 127 [18:43:04] <viperhoot>  nos dan sugerencias de cual puede ser el paquete adecuado de acuerdo lo que dice el informe
 128 [18:43:25] <viperhoot>  Por ejemplo: si son fallos relacionados a firefox (como este caso) probablemente el paquete sea "firefox-3.5"
 129 [18:43:44] <viperhoot>  si son fallos relacionados a la impresora, seguramente el paquete sea "cups". Tienen toda una guia en ese enlace ;)
 130 [18:44:11] <viperhoot>  en nuestro caso del bug de demostración relacionado a firefox: el paquete es firefox-3.5
 131 [18:44:37] <viperhoot>  En la sección Status (estado), la opción New (nuevo) es como ya dije, el estado de cada nuevo reporte
 132 [18:45:04] <viperhoot>  El incompleto (incomplete) generalmente se marca por alguien que adopta este reporte y requiere mas informacion que consultar a la persona
 133 [18:45:29] <viperhoot>  Confirmado (Confirmed) es bueno.. , cuando el reporte tiene la informacion suficiente y el bug es reproducible.
 134 [18:45:38] <viperhoot>  tambien existen otros estados
 135 [18:46:03] <viperhoot>  Fix commited (Se ha enviado la corrección del problema a los desarrolladores pero aun no se ha publicado en los repositorios)
 136 [18:46:24] <viperhoot>  Fix released: La solucion al problema se ha publicado oficialmente en los repositorios
 137 [18:46:43] <viperhoot>  Won't fixed: Esto es un poco controversial y significa que no puede ser reparado.
 138 [18:47:01] <viperhoot>  In progress: Se esta trabajando aun para solucionar este problema
 139 [18:47:25] <viperhoot>  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
 140 [18:48:01] <viperhoot>  La sección Importance (importancia) tampoco se puede modificar ya que es necesario pertenecer al equipo de ubuntu bug control para ello.
 141 [18:48:34] <viperhoot>  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)
 142 [18:48:57] <viperhoot>  Trabajaremos con el reporte ficticio sobre un error de Firefox al ver xxxx página
 143 [18:49:49] <viperhoot>  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)
 144 [18:50:12] <viperhoot>  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
 145 [18:50:54] <viperhoot>  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.
 146 [18:52:07] <viperhoot>  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)
 147 [18:52:47] <viperhoot>  Importance estará bloqueado por defecto, no podremos mover nada allí
 148 [18:52:56] <viperhoot>  Para rellenar la sección Assigned to: Crees poder trabajar en una solución a este error?
 149 [18:53:09] <viperhoot>  En este caso no será así, por lo que dejamos la opción en Nobody.
 150 [18:53:37] <viperhoot>  Si lo deseamos podemos dejar algún comentario acerca de las modificaciones hechas, en inglés de preferencia, aunque esto es totalmente opcional.
 151 [18:53:59] <viperhoot>  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
 152 [18:54:18] <viperhoot>  podremos necesitar saber la versión de java o de flash instalada o la cantidad de extensiones extras instaladas
 153 [18:54:30] <viperhoot>  Un buen lugar para solicitar esta información al autor del reporte es en la sección de comentarios ;)
 154 [18:54:52] <viperhoot>  Hay una serie de respuestas predefinidas para diversas situaciones de los reportes, las pueden revisar aqui: https://wiki.ubuntu.com/Bugs/Responses
 155 [18:55:03] <viperhoot>  *Recuerden que deben estar escritas en inglés, así nos entendemos mejor todos ;)
 156 [18:55:26] <viperhoot>  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
 157 [18:55:38] <viperhoot>  con mensajes informativos a nuestro buzón de correo. Una manera sencilla de hacerle seguimiento.
 158 [18:56:05] <viperhoot>  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.
 159 [18:56:31] <viperhoot>  reo que eso es todo para empezar con el trabajo de triaging.
 160 [18:56:52] <viperhoot>  Algunos enlaces que les pueden servir para reforzar esta breve charla
 161 [18:56:57] <viperhoot>  https://wiki.ubuntu.com/Jams/ES/Bugs
 162 [18:57:00] <viperhoot>  https://wiki.ubuntu.com/BugSquad/KnowledgeBase/
 163 [18:57:03] <viperhoot>  https://wiki.ubuntu.com/Bugs/EasyTasks
 164 [18:57:07] <viperhoot>  https://wiki.ubuntu.com/Bugs/HowToTriage
 165 [18:57:17] <viperhoot>  Aquí finaliza la charla sobre cómo trabajar con bugs
 166 [18:57:23] <viperhoot>  Por mi parte gracias por su atención y ojalá les haya gustado ;)
 167 [18:57:31] <viperhoot>  Dudas en #ubuntu-centroamerica-chat
 168 [18:57:53] <alucardni>  muchas gracias viperhoot
 169 [18:58:20] <viperhoot>  Un gusto, nos leemos en alguna otra ocasión ;)