Re: On the road to (GNU) debbugs support, some blockers

[Kyle Meyer <kyle@kyleam.com>]

Jelle Licht writes:

>> Have you tried using :listid?  For example, for guix-patches, I use
>> "guix-patches.gnu.org".
>
> I'm using the debbugs.el interface to read the messages, which
> may-or-may-not present a very idiosyncratic version of the messages:
>
> --8<---------------cut here---------------start------------->8---
> ...
> List-Id: <debbugs-submit.debbugs.gnu.org>
> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
> List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
> List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
> X-GNU-PR-Package: guix-patches
> ...
> --8<---------------cut here---------------end--------------->8---

Ah, debbugs.el was the piece I was missing.  I've played around with
debbugs.el a bit in the past, but never used it for real and haven't
considered it in the context of piem.

>> If X-GNU-PR-Package is better than List-Id for some users/cases, I'm
>> open to adding support for it.  It should be sufficient to teach
>> piem-inbox-by-header-match to consider that header (along with an
>> associated piem-inboxes key).
>
> 'Better' is a big word, but the X-GNU-PR-Package header is the only one
> that is really exposed via the debbugs interface afaics.

I'll look into debbugs.el a bit more because I don't have a good
understanding of where it's getting the messages from and how it's
interacting with Gnus, but it sounds like the X-GNU-PR-Package header is
the way to go for debbugs.el support.

I'm curious whether it will make sense to have a custom integration
library, perhaps one that builds on top of piem-gnus, but perhaps that
will be clearer once I take a closer look.

> As mentioned, I use debbugs.el to interact with the issue tracker. [1]
> Using guix:
> `guix shell emacs emacs-debbugs -- emacs':
>
> Evaluate:
> `(debbugs-gnu '("serious" "important" "normal") '("guix-patches") nil t)'
>
> Go to any issue, and open a message. [...]

Thanks, those concrete steps are helpful.

> [1]: Not entirely relevant to the issue at hand, but I also have all
> guix-patches messages available and indexed in my local notmuch
> setup. When I use piem-gnus /w my modifcations, in combination with
> piem-notmuch to apply patches using `piem-b4-am', the relevant messages
> are actually not even downloaded from the yhetil public inbox, since the
> messages with the message-ids are already found locally! Really
> wonderful design and/or some convenient emergent properties of how piem
> does things.

I'll claim it's design, unless someone's complaining, then it's just an
unfortunate emergent property :)

But, yeah, the idea is that users can put local retrieval methods in
piem-mid-to-thread-functions, ordered by their preferred sources, and
then those sources are given priority regardless of where piem-mid is
extracting the message ID from.  The main downside is that a given local
source that has the specified message ID doesn't necessarily have all
the thread's messages.

This approach has worked nicely for me because I have all of yhetil
inboxes mirrored locally and indexed with lei but have yet to flesh out
piem-lei enough to move away following lists via NNTP with Gnus [*].

[*] Aside from dev testing, I haven't used or relied on
    piem-gnus-mid-to-thread myself.  My testing prompted by your message
    hit into some encoding issues, so it looks like it needs some work
    beyond the debbugs.el case you raised.