Ver el código de «Gestión de errores y otros temas en Software libre»

{{Sección
|Título=Gestión de errores y otros temas
|Libro=Software libre
|Capítulo=Entornos y tecnologías de desarrollo
|Número sección=7
|Introducción=Uno de los puntos fuertes del modelo de desarrollo libre es que la comunidad contribuya con informes de errores, y que ella sienta que sus informes o soluciones son tenidos en cuenta. Por ello es necesario un mecanismo sencillo de informar de errores, de modo que los desarrolladores reciban información suficiente, de forma sistemática, y con todos los detalles necesarios, ya sea aportados por el colaborador, como la explicación de lo que pasa, nivel de importancia y posible solución, ya por algún mecanismo automático que determine, por ejemplo, la versión del programa y del entorno en que funciona. Así mismo es necesario que los errores se guarden en una base de datos que pueda ser consultada, para ver si un error ya ha sido reportado, si ha sido corregido, su nivel de importancia, etc.

Existen varios de estos sistemas, de filosofía diferente. Unos son vía Web, otros vía correo electrónico, por medio de algún programa intermediario. Todos tienen interfaz Web para consulta. Unos permiten informes anónimos, otros requieren identificación (una dirección de correo válida), para evitar el ruido. Aunque los procedimientos vía Web parecen los más sencillos, con ellos no es posible obtener fácilmente información automática del entorno del error. Por ejemplo, el sistema de Debian proporciona programas como reportbug, que tras preguntar el nombre del paquete sobre el que queremos informar, consulta al servidor de errores qué errores ya hay reportados sobre el mismo. Si ninguno de ellos se refiere a nuestro problema, nos pide una descripción del mismo, un nivel de importancia (crítico, grave, serio, importante, no se puede regenerar a partir de los fuentes, normal, menor o sugerencia) y etiquetas sobre la categoría (por ejemplo, seguridad). Tras ello, si confirmamos la petición, automáticamente averigua la versión del paquete y de aquellos de los que depende, así como la versión y arquitectura del núcleo. Obviamente la dirección de correo electrónico la sabe, por lo que un informe similar al siguiente es enviado al sitio correcto:

<pre>
Package: w3m-ssl
Version: 0.2.1-4
Severity: important

After reloading a page containing complex tables several dozen times, w3m had
used all physical memory and thrashing commenced. This is an Alpha machine.

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux romana 2.2.19 #1 Fri Jun 1 18:20:08 PDT 2001 alpha unknown

Versions of the packages w3m-ssl depends on:
ii  libc6.1     2.2.3-7        GNU C Library: Shared libraries and Timezone data
ii  libgc5      5.0.alpha4-8   Conservative garbage collector for C
ii  libgpmg1    1.19.3-6       General Purpose Mouse Library [libc6]
ii  libncurses5 5.2.20010318-3 Shared libraries for terminal handling
ii  libssl0.9.6 0.9.6a-3       SSL shared libraries
ii  w3m         0.2.1-2        WWW browsable pager with tables/frames support
</pre>

Este mensaje genera un número de error que nos es devuelto, enviado al mantenedor y guardado en la base de datos. Cuando se resuelva el error, recibiremos también una notificación. Cada error tiene asignada una dirección de correo electrónico que se puede utilizar para proporcionar información adicional, por ejemplo. La base de datos de errores la podremos consultar vía http://bugs.debian.org en cualquier momento.

A veces los sistemas de seguimiento de errores tienen mecanismos para asignar la corrección a alguien y ponerle un plazo. También existen otros temas, como trabajos pendientes, mejoras solicitadas, traducciones, etc, que requiren también mecanismos de gestión similares. En software libre generalmente no se pueden emplear mecanismos muy rígidos de gestión de los trabajos que tiene que hacer cada desarrollador. Después de todo muchos colaboradores son voluntarios y no se les puede obligar a nada. No obstante sí se pueden definir tareas y esperar a que alguien se de de alta en el sistema y las asuma, declarando un plazo para ello. Se tenga o no control sobre lo que pueden hacer determinadas personas, siempre es conveniente tener controladas las tareas que hay que hacer, qué dependencias tienen, su nivel de importancia y quiénes están trabajando en ellas. Muchos de los proyectos importantes gestionan estos temas con BugZilla[bugzilla:guide] o derivados del mismo.

A veces una persona trabajando en un proyecto puede descubrir errores en otro del que depende su trabajo, pero que tiene un sistema de gestión de errores distinto al que está acostumbrada. Esto es especialmente cierto para usuarios de distribuiciones, que quieren utilizar una única herramienta para informar y seguir la corrección de sus errores. Para facilitar el informe y seguimiento de esos errores puede ser conveniente federar distintos sistemas, como hace Malone [malone].
|Apartados=
|Estado=completo
}}
{{Prueba
|Prueba=No
}}