[Top][All Lists]

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

Re: Updating mumi on berlin

From: Arun Isaac
Subject: Re: Updating mumi on berlin
Date: Tue, 03 May 2022 23:03:46 +0530

Hi zimoun,

> Is the update of Mumi done?

Mumi has been patched with a proof-of-concept GraphQL API. See;a=commit;h=f5232c49fe8a3b127c96f7b502775f16aebf3033
But, I don't know if mumi has been reconfigured on berlin yet. Still
waiting on Maxim for that one.

> Well, this GraphQL API could ease the current workflow, IMHO.
> Today, one has to subscribe and it is not easy to locally read the
> archives or follow what is going in.  The Emacs front-end to Debbugs
> helps but Emacs is not always popular.

Indeed, one of my motivations with the GraphQL API is to "liberate" some
of our power tools from Emacs' grip. As much as I love Emacs, I
understand that not everybody does. So, it's important to strengthen our
presence outside Emacs as well.

> Debian has this CLI tool [1], allowing to request against Debbugs.  It
> could be nice to have a similar tool based on the top of Mumi.
> And for instance, using this ’bts’ Debian script, it is “easy“ to have
> other scripts for importing [2] bugs to any mail reader using Maildir.
> Given a bug number, it allows to download all the thread of that bug.
> We could package these Debian scripts and tweak them to work with the
> Guix instance… Or maybe we could have some Scheme scripts. ;-)

I didn't know about bts. Thanks for the reference. We could always
support both but I daresay we might have more fun with Scheme scripts!

> About Message-ID and Mumi, yeah… for example, it is just an instant
> using notmuch for finding the patch where you tweak Xapian and ‘guix
> search’.  But to publicly refer to it, I have to open my browser scroll
> and scroll again, and found it; the 14th message in the thread.  Well,
> since I can easily stash the Message-ID from notmuch and I can easily
> build an URL with it, then I think that:
> redirecting to,
> would simplify my workflow. :-)  It appears to me weird that all is
> built around email but core components as Message-Id is barely used.

I totally agree. We should be able to support something based on
Message-ID like you suggested.


reply via email to

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