knocte :: MonoTema

Parece que los programas de workflow están de moda. Sobre todo los basados en web, que son muy fáciles de instalar (para el usuario, que no de administrar para el sysadmin) pues sólo se necesita un navegador.

En realidad, ¿qué es un workflow? Es un concepto un poco "cajón de sastre" pero básicamente es un software que te permite archivar, monitorizar, en general ayudarte a gestionar las tareas en un entorno de trabajo. Hay workflows más generales (como eGroupWare) y otros más específicos (como por ejemplo Bugzilla, que se centra en la gestión de bugs [defectos] en el software).

La verdad es que yo soy un enamorado de Bugzilla y siempre he pensado que se podría usar como workflow "general" a falta de alguna que otra funcionalidad, como wikis, calendarios con timelines/roadmaps, etc. Porque yo creo que es el software de gestión de incidencias más maduro y completo que existe.

¿Y por qué ahora he utilizado la palabra incidencia en lugar de defecto? Pues porque hay una interesante polémica desde hace bastante, en torno a este software, que consiste en que un cierto grupo numeroso de personas abogan porque esta herramienta gestione no sólo defectos o petición de nuevas funcionalidades (enhancements) sino también simples y llanas "tareas". Luego existen otros dos grupos en contra de esto: los primeros se escudan en que Bugzilla nació para ser un software de seguimiento de defectos del software, y no más, y luego hay otros que aseguran que un "bug" también puede ser válido como acepción general de una tarea.

Yo a estos últimos les preguntaría ¿la tarea de, por ejemplo, configurar un apache, se podría considerar un bug? A mí me suena un poco raro... Pero no me voy a casar con nadie, así que yo he encontrado mi solución particular, jugando con los "value fields" de Bugzilla, ya que originalmente contienen:

Gravedad/Severity: blocker, critical, major, normal, minor, trivial, enhancement
Prioridad/Priority: P1, P2, P3, P4, P5, P6

Si nos fijamos, el campo de prioridad es tan poco descriptivo que ni siquiera sabemos si P1 es el más o el menos prioritario; y el segundo es tan ambiguo que parece que en sus valores se están mezclando prioridad, gravedad, complejidad, y tipo de incidencia. Así que yo he optado por usar los valores siguientes

Severity (gravedad): critical defect, major defect, normal defect, slight defect, improvement, new feature, task.
Priority (prioridad): undecided, showstopper, urgent, normal, interesting, desirable

Con esto yo creo que resolvemos el problema de la ambigüedad de la gravedad y a la vez tenemos un workaround para el bug #88177 ;)

Para cubrir las necesidades de workflow que no cubre este "bugzilla parcheado" podemos recurrir a eGroupware o derivados. Sin embargo, puesto que soy un ex-programador PHP, en el sentido en el que cuando me cambio de equipo ya no puedo ni acordarme de lo antiguo, pues siempre me atraerán más los proyectos que se casen con una arquitectura de desarrollo más decente. Es el caso del recién nacido NProject el cual usa el eficiente CastleProject (que usa por debajo MonoRail, ActiveRecord + NHibernate, etc.) el cual es un framework que es el resultado de un port de Ruby on Rails a C#. Parece que en cuestión de frameworks web MVC, éste junto a Maverick.NET y Spring.NET son los más populares.

Otros podrían decirme: "¡pues Bugzilla está programado en Perl, ¿qué me dices de eso?" En cuyo caso respondería: ojalá tuviera tiempo de emprender mi propio proyecto "NBugzilla" o "MonoBugz" para conseguir, no sólo una herramienta divertida de usar, sino divertida de programar y extender. Y es que podríamos hacer uso de una arquitectura bastante apetecible en la que manejar casi cualquier base de datos gracias a NHibernate (al contrario que el Bugzilla actual que sólo soporta MySQL y PosgreSQL), o bien una base de objetos como DB4O, o bien soporte configurable para ambas cosas, etc. Es un proyecto que propuse en el GoogleSoC pero que evidentemente distaba mucho de ser aceptado :)

Volviendo un poco desde las ramas, me gustaría comentar mis andanzas a la hora de instalar este workflow que me gusta tanto: la primera vez lo instalé desde las fuentes en una distro Mandriva, la segunda con un RPM automático (aunque al final no tan automático, ¡oye!) en otra versión mejor de Mandriva, y esta tercera ha sido en una Ubuntu, con los siguientes procesos prueba-error (es una pena que OpenSUSE no incluya un paquete para Bugzilla):

1. Instalación del paquete del repositorio universe, versión 2.20, con mucho miedo (las cosas no oficiales, es lo que tiene).
2. Problemas de configuración.
3. Problemas con el envío de correo.
4. Desinstalación de sendmail e instalación de postfix.
5. Errores de corrupción de tablas MySQL.
6. Reinstalación desde cero.
7. Problema con los caracteres internacionales (tildes, eñes, ...) en el envío de correo; al parecer resueltos por la versión siguiente (v. 2.22) gracias a UTF-8.
8. No existe la versión 2.22 en Ubuntu Dapper.
9. No parece que estén disponibles todavía los paquetes de Ubuntu inestable.
10. Localización del paquete de Debian Sid (inestable) con la versión 2.22.
11. Desinstalación y purgado de lo antiguo.
12. Instalación del paquete de Debian en Ubuntu.
13. Problemas de configuración no resueltos.
14. Tiro la toalla e instalo el programa desde fuentes.
15. Versión obsoleta del módulo estable de CPAN llamado Mail::Mailer.
16. No hay versión inestable Debian/Ubuntu del mencionado módulo.
17. Instalación manual del paquete por CPAN.
18. Configuración correcta.
19. Todo funcionando correctamente.

Sólo tengo clavada una pequeña espinita (al parecer asignada para su implementación en la 2.24).

Me ha gustado esta versión: la configuración general del programa (malamente llamada "Parameters") ahora está dividida en secciones por temas; existe opción de editar automáticamente los "Field values" de los que ya os he hablado, sin la antigua necesidad de recurrir a un fichero de texto y especificarlos al inicio para luego ser inmutables.

Actualización 03-SEP-2006: Parece ser que el concepto de Workflow es algo más subjetivo y diluido como para asociarlo a este tipo de gestores de incidencias. Parece que hay gente que lo atribuye más a programas de gestión de diagramas de flujo (los típicos que dibujamos los informáticos antes de describir un algoritmo), o incluso otros van más por el lado ERP, y un ejemplo concreto es el NetBPM, al parecer hecho con y usado por el proyecto Mono, que tiende más a la gestión al estilo Microsoft Project, en el que podemos incluso gestionar peticiones de vacaciones de los empleados (una demo aquí).

Actualización 17-NOV-2006: También me gusta más renombrar el estado ASSIGNED a INPROGRESS, lo que se puede hacer editando el fichero /var/www/bugzilla/template/en/default/global/field-descs.none.tmpl a partir de la versión 2.20.

Actualización 2-FEB-2006: Resulta que cambiando el valor a INPROGRESS en el punto en el que he mencionado antes, sólo lo cambia para la intefaz gráfica pero el valor lo sigue poniendo como ASSIGNED en los emails enviados, así que voy a investigar como se hace el cambio bien. Otra cosa que echo en falta es un campo nuevo para la "complejidad de la solución estimada", que bien podría dividirse en dos: un campo con valor enumerado, y otro con una estimación de tiempo de resolución de la incidencia.

Actualización 20-MAY-2006: Vaya, viendo esta página sobre Bugzilla puedo comprobar que se empieza a imponer el sentido común: y es que usar Perl para una herramienta tan grande empieza a verse como un handicap, y se están proponiendo alternativas para reescribirlo desde cero. Como no, he colocado mis propuestas en la página de discusión, máxime al ver que no existía una sección de Mono y sólo un párrafo hablando de C#. Si Mono no se lleva el gato al agua (que parece ser lo más seguro, dado el poco apoyo que tiene), espero que al menos gane Java.

Actualización 04-NOV-2007: Otra característica interesante de bugzilla para poderle cambiar la cara y que se adapte más a una herramienta de tipo genérico de ticketing o workflow, es la capacidad de cambiar la palabra "bug" por otra distinta, como "issue" o "ticket". Aquí más información.

Actualización 13-MAY-2009: Resulta que el tema de que las prioridades predeterminadas no son entendibles y el bug de que Enhancement sea un valor del campo "Severity" tienen sus correspondientes bugs abiertos!:
- Bug classification field: este bug tiene nada más y nada menos que 10 años de edad.
- Default Priority values are unclear: ya he aportado mi sugerencia aquí :)

Labels: General, Mono, Mozilla, Programacion, SoftwareLibre, WebDev