[Top][All Lists]

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

Re: debbugs irritation Was: [WIP Patch] Adding an FHS container to guix

From: zimoun
Subject: Re: debbugs irritation Was: [WIP Patch] Adding an FHS container to guix shell
Date: Thu, 18 Aug 2022 12:55:52 +0200


On Thu, 21 Jul 2022 at 22:22, Csepp <> wrote:

> Mumi and Debbugs have different search interfaces and seem to use
> different ordering.

Hum, I am confused because from my understanding, there is one Debbugs
instance – which is quickly said some Perl scripts managing mailing
lists and thus implementing a bug tracker database.  This database is
then manipulated via SOAP-interface.

This Debbugs instance is out of the control of the Guix project, AFAIK.

On the top of this instance, various front-ends are implemented:

 + historical one running at: 
 + Mumi running at:
 + emacs-debbugs running locally

And even Debian folks provide many others, as python3-debianbts or
reportbug coming with the CLI tool bts, mailscripts, etc.

> IMHO these papercuts add up.  Browsing and cross-referencing issues and
> patches is way harder than it is with other forges.

Well, harder depends on the point of view. :-)

Indeed, you need more than just type bug#12345 to cross-link.  Using a
descent mailreader, it appears to me easy to have helper.  For instance,
using Emacs, I have a custom function [1] “M-x my/guix-issues“ which
adds to the kill-ring an URL.  Recently, Ricardo added Message-ID to
Mumi which helps too; using emacs-notmuch, just "ci” for stashing and
then pasting elsewhere.


About browsing, Mumi needs more love. :-)

> Not saying we need to switch, maybe it's easier to just add the missing
> functionality.  Or maybe it doesn't matter to anyone else.

Well, the GNU instance of Debbugs has many flaws.  But the project will
not switch from it, IMHO.  That’s why Mumi as front-end tries to improve
the situation by adding the missing functionalities.


reply via email to

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