[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Working towards a new implementation of Debbugs?

From: Ricardo Wurmus
Subject: Working towards a new implementation of Debbugs?
Date: Tue, 07 Apr 2020 18:38:08 +0200
User-agent: mu4e 1.2.0; emacs 26.3

Hello there,

some years ago I felt the urge to provide an alternative web interface
to Debbugs that did just two things:

1) look similar to Github issues (and less like a somewhat intimidating
industrial bug tracker), and

2) offer an uncomplicated, fast full-text search

The reason for that was that many new contributors to Guix were not all
Emacs users and thus used the bug tracker via its web interface (or by
browsing the mailing list archives) instead of debbugs.el.  The web
interface was often considered confusing and its appearance austere.
The goal was also to answer to requests for having Guix “move to
Git{hub,lab}, because they have an issue tracker that’s easier to use”.

This led to Mumi, the “mediocre, uh, mail interface”:

It is written in Guile and uses a Xapian database for the full-text
search.  Initially it used the Debbugs SOAP service for everything: for
fetching bug messages, bug status, etc.  A known bug in the SOAP service
that leads to truncation of multipart messages made us switch to talking
to the existing web interface to fetch the unmodified raw emails.

Recently, Mumi gained support for submitting comments via the web
interface, implementing this wishlist item from 10 years ago:

An instance of Mumi is used by the Guix project and is available here:

(Comment submission is currently disabled as I’m fighting with data
centre firewall settings…)

Last I heard the GNU instance of Debbugs was looking for someone to pick
up maintainenance, to “despecialize” it with regard to the upstream
version used by Debian.  I wonder if there might be value in switching
to a new implementation of a Debbugs-like system written in Guile by
extending Mumi.  Just like Debbugs, Mumi works with raw emails that
reach its mailbox, so it is not *radically* different.

Mumi was written as a “client” to a Debbugs “backend”, so of course it
is currently missing a bunch of features that Debbugs has:

* a SOAP service for debbugs.el
* handling of incoming email
* maintaining bug state by interpreting control messages

Writing Mumi in Guile has been very enjoyable and I would be happy to
add those features if there is interest in using it as a replacement for
the current GNU fork of Debbugs.

What do you think?  Is this worth pursuing?


PS: to avoid hitting the web interface too hard to fetch
mbox files, would it be possible to get rsync access to the file system
holding the raw mbox files?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]