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

[zimoun]

Hi,

On Thu, 21 Jul 2022 at 22:22, Csepp <raingloom@riseup.net> 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: https://debbugs.gnu.org 
 + Mumi running at: https://issues.guix.gnu.org/
 + emacs-debbugs running locally

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

https://git.spwhitton.name/mailscripts/tree/

 
> 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.

1: 
<https://gitlab.com/zimoun/my-conf/-/blob/master/.config/emacs/lisp/funs.el#L271-300>


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.


Cheers,
simon