Hi zimoun,
> Is the update of Mumi done? Mumi has been patched with a proof-of-concept GraphQL API. See https://git.elephly.net/gitweb.cgi?p=software/mumi.git;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: > > > https://issues.guix.gnu.org/20200227204150.30985-1-arunis...@systemreboot.net > > redirecting to, > > https://issues.guix.gnu.org/39258#14 > > 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. Cheers! Arun