Gnus development mailing list
 help / color / Atom feed
* Gnus backend for GitHub/GitLab?
@ 2019-11-19 22:11 Adam Sjøgren
  2019-11-20  3:31 ` Eric Abrahamsen
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Adam Sjøgren @ 2019-11-19 22:11 UTC (permalink / raw)
  To: ding

Watching this video about Magit Forge:

 · https://cestlaz.github.io/post/using-emacs-62-magit-forge/

It hit me that accessing comments on GitHub/GitLab seems like an obvious
candidate for a Gnus backend.

  * GitHub/GitLab-instance: a Gnus server
  * Each project you're interested in: a subscribed group
  * Each issue: a top-level article
  * Each comment: replies to issues/other comments
  * Label, State ...: headers that can be edited

I guess Pull/Merge Requests could also be articles in the group, only
with other default headers shown.

So what I am thinking of is, say, nntp+gitlab.com:bashrc2.epicyon as the
group, for instance, with articles:

 [Klaus Alexander Seistrup] User and status links: reorganisation?
 [Alex Schroeder          ] System load
     [Bob Mottram            ]
         [Alex Schroeder         ]
             [Bob Mottram            ]
                 [Bob Mottram            ]
                    [Bob Mottram            ]
                        [Alex Schroeder         ]
                            [Bob Mottram            ]
                               [Bob Mottram            ]

(Mapped from https://gitlab.com/bashrc2/epicyon/issues)

Something like that.

Closing an issue could be editing the root-article and updating a
"Status:" header from "open" to "closed". Changing labels would be
editing the "Keywords:" header. Deleting would be cancelling the
article. Creating a new issue: posting a new article. Commenting
following up.

For public projects you could use scoring to ignore comments from
trolls. Or bulk delete spam.

I think Gnus would be better suited to this than Magit Forge. Well, if
you're using Gnus anyway, anyway.

If I had a backend like this, I could turn off notification emails from
GitLab at work, and I would never have to use the web-interface.

(Well, Gnus would have to support Kerberos in web-requests, so I could
see the images in the issues, but except for that.)

The more I think about this, the more I like it. Gnus all the things!

What do you think?


  Best regards,

    Adam

-- 
 "I wish *I* was a tiger!"                                     Adam Sjøgren
 "A common lament."                                       asjo@koldfront.dk
 




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-19 22:11 Gnus backend for GitHub/GitLab? Adam Sjøgren
@ 2019-11-20  3:31 ` Eric Abrahamsen
  2019-11-20  4:12 ` dick.r.chiang
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2019-11-20  3:31 UTC (permalink / raw)
  To: ding

Adam Sjøgren <asjo@koldfront.dk> writes:

> Watching this video about Magit Forge:
>
>  · https://cestlaz.github.io/post/using-emacs-62-magit-forge/
>
> It hit me that accessing comments on GitHub/GitLab seems like an obvious
> candidate for a Gnus backend.
>
>   * GitHub/GitLab-instance: a Gnus server
>   * Each project you're interested in: a subscribed group
>   * Each issue: a top-level article
>   * Each comment: replies to issues/other comments
>   * Label, State ...: headers that can be edited
>
> I guess Pull/Merge Requests could also be articles in the group, only
> with other default headers shown.
>
> So what I am thinking of is, say, nntp+gitlab.com:bashrc2.epicyon as the
> group, for instance, with articles:
>
>  [Klaus Alexander Seistrup] User and status links: reorganisation?
>  [Alex Schroeder          ] System load
>      [Bob Mottram            ]
>          [Alex Schroeder         ]
>              [Bob Mottram            ]
>                  [Bob Mottram            ]
>                     [Bob Mottram            ]
>                         [Alex Schroeder         ]
>                             [Bob Mottram            ]
>                                [Bob Mottram            ]
>
> (Mapped from https://gitlab.com/bashrc2/epicyon/issues)
>
> Something like that.
>
> Closing an issue could be editing the root-article and updating a
> "Status:" header from "open" to "closed". Changing labels would be
> editing the "Keywords:" header. Deleting would be cancelling the
> article. Creating a new issue: posting a new article. Commenting
> following up.
>
> For public projects you could use scoring to ignore comments from
> trolls. Or bulk delete spam.
>
> I think Gnus would be better suited to this than Magit Forge. Well, if
> you're using Gnus anyway, anyway.
>
> If I had a backend like this, I could turn off notification emails from
> GitLab at work, and I would never have to use the web-interface.
>
> (Well, Gnus would have to support Kerberos in web-requests, so I could
> see the images in the issues, but except for that.)
>
> The more I think about this, the more I like it. Gnus all the things!
>
> What do you think?

I think it's exhausting just to imagine the amount of work that would
take :)

But in principle I think it's a great idea, and I definitely think we
should be pushing the boundaries of what counts as a Gnus server. So many
things could be thought of as groups of sequential messages.

I look forward to your code!

Eric




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-19 22:11 Gnus backend for GitHub/GitLab? Adam Sjøgren
  2019-11-20  3:31 ` Eric Abrahamsen
@ 2019-11-20  4:12 ` dick.r.chiang
  2019-11-20 11:33 ` Lars Ingebrigtsen
  2020-01-14 20:42 ` Adam Sjøgren
  3 siblings, 0 replies; 15+ messages in thread
From: dick.r.chiang @ 2019-11-20  4:12 UTC (permalink / raw)
  To: Adam Sjøgren; +Cc: ding

I have some experience in this area.  Nearly everything we consume on the
internet fits the threaded message queue model.  Lars et al saw this fairly
early on.  The key though is an API that admits a sequence-numbered stream per
group to track "new messages since last visited."  A quick glance at
gitlab's API doesn't suggest it's on offer, and inferring such a record by
scanning html would be fragile and unwieldy.

There are also code-citation and push-button functionalities (merging PRs,
etc.) that are better served by point-and-click ui's.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-19 22:11 Gnus backend for GitHub/GitLab? Adam Sjøgren
  2019-11-20  3:31 ` Eric Abrahamsen
  2019-11-20  4:12 ` dick.r.chiang
@ 2019-11-20 11:33 ` Lars Ingebrigtsen
  2019-11-20 12:38   ` Adam Sjøgren
  2020-01-14 20:42 ` Adam Sjøgren
  3 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-20 11:33 UTC (permalink / raw)
  To: Adam Sjøgren; +Cc: ding

Adam Sjøgren <asjo@koldfront.dk> writes:

> It hit me that accessing comments on GitHub/GitLab seems like an obvious
> candidate for a Gnus backend.
>
>   * GitHub/GitLab-instance: a Gnus server
>   * Each project you're interested in: a subscribed group
>   * Each issue: a top-level article
>   * Each comment: replies to issues/other comments
>   * Label, State ...: headers that can be edited

That would indeed be nice, but the main problem with the APIs that
Gitlab provides is that...  they're very chatty and aren't geared
towards "show me what's changed since <foo>" (which is what Gnus thrives
on).

This means that you have to issue a whole bunch of API requests just to
get the basic info, which means that things get very s-l-o-w.

But I've just skimmed the Gitlab API documentation; perhaps it has
what's needed to make things go fast.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-20 11:33 ` Lars Ingebrigtsen
@ 2019-11-20 12:38   ` Adam Sjøgren
       [not found]     ` <87h82ywu6i.fsf@gmx.de>
  2019-11-21 12:31     ` Lars Ingebrigtsen
  0 siblings, 2 replies; 15+ messages in thread
From: Adam Sjøgren @ 2019-11-20 12:38 UTC (permalink / raw)
  To: ding

Lars writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>> It hit me that accessing comments on GitHub/GitLab seems like an obvious
>> candidate for a Gnus backend.
>>
>>   * GitHub/GitLab-instance: a Gnus server
>>   * Each project you're interested in: a subscribed group
>>   * Each issue: a top-level article
>>   * Each comment: replies to issues/other comments
>>   * Label, State ...: headers that can be edited
>
> That would indeed be nice, but the main problem with the APIs that
> Gitlab provides is that...  they're very chatty and aren't geared
> towards "show me what's changed since <foo>" (which is what Gnus thrives
> on).

I think this is what Michael Albinus addressed - in an email that seems to
be stuck in the mailing list flow somewhere - where he wrote:

    GET /projects/<id>/issues?scope=all&updated_after=2019-11-19T13:22:55.640Z

    <id> is your project id.

    Best regards, Michael.

That might be useful?

Anyway, I intend to use this against quite small projects (i.e. not
Emacs sized, but more in the thousands of issues).

> This means that you have to issue a whole bunch of API requests just to
> get the basic info, which means that things get very s-l-o-w.

Are you thinking of having to fetch all comments for all issues again
and again, or?

I *am* worried about ending up with yet-another-nnslashdot backend,
which is so dog slow that it is unusable...

> But I've just skimmed the Gitlab API documentation; perhaps it has
> what's needed to make things go fast.

Alternatively I could build a "gitlab_to_nntpd", but I think the
integration (especially with changing labels and status by editing
articles, rather than superseding), would be easier/better if it is a
backend that Gnus knows that editing directly works for?

Another thing I was thinking was that maybe nngitlab could build upon
the code in Magit Forge that already exists to talk to the APIs... but
given my level of familiarity with elisp, I might just start attempting
the simplest possible.


  Best regards,

    Adam

-- 
 "I wish *I* was a tiger!"                                     Adam Sjøgren
 "A common lament."                                       asjo@koldfront.dk
 




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
       [not found]     ` <87h82ywu6i.fsf@gmx.de>
@ 2019-11-20 15:01       ` Adam Sjøgren
       [not found]         ` <87h82yvb7r.fsf@gmx.de>
  0 siblings, 1 reply; 15+ messages in thread
From: Adam Sjøgren @ 2019-11-20 15:01 UTC (permalink / raw)
  To: Michael Albinus; +Cc: ding

Michael writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>> Another thing I was thinking was that maybe nngitlab could build upon
>> the code in Magit Forge that already exists to talk to the APIs... but
>> given my level of familiarity with elisp, I might just start attempting
>> the simplest possible.
>
> Forge is tightly linked with Magit, calling magit-* functions.

Ok, I was just hoping the interface to GitLab/Microsoft GitHub/etc. was
separated out and perhaps could be reused, but if not, so be it.

> Not everybody uses Magit.

I don't think I claimed that :-)


  Best regards,

    Adam

-- 
 "I wish *I* was a tiger!"                                     Adam Sjøgren
 "A common lament."                                       asjo@koldfront.dk
 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
       [not found]         ` <87h82yvb7r.fsf@gmx.de>
@ 2019-11-20 15:35           ` Adam Sjøgren
  0 siblings, 0 replies; 15+ messages in thread
From: Adam Sjøgren @ 2019-11-20 15:35 UTC (permalink / raw)
  To: Michael Albinus; +Cc: ding

Michael writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>>>> Another thing I was thinking was that maybe nngitlab could build upon
>>>> the code in Magit Forge that already exists to talk to the APIs... but
>>>> given my level of familiarity with elisp, I might just start attempting
>>>> the simplest possible.
>>>
>>> Forge is tightly linked with Magit, calling magit-* functions.
>>
>> Ok, I was just hoping the interface to GitLab/Microsoft GitHub/etc. was
>> separated out and perhaps could be reused, but if not, so be it.
>
> These days I'm playing with Ghub, the working horse of Forge. Also from
> Jonas Bernoulli, also on melpa. Works fine for me.

Now I'm confused. Didn't you just say that the code Magit Forge uses to
talk to the various APIs is tightly linked with Magit?!


  Best regards,

    Adam

-- 
 "I wish *I* was a tiger!"                                     Adam Sjøgren
 "A common lament."                                       asjo@koldfront.dk
 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-20 12:38   ` Adam Sjøgren
       [not found]     ` <87h82ywu6i.fsf@gmx.de>
@ 2019-11-21 12:31     ` Lars Ingebrigtsen
  1 sibling, 0 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-21 12:31 UTC (permalink / raw)
  To: Adam Sjøgren; +Cc: ding

Adam Sjøgren <asjo@koldfront.dk> writes:

> I think this is what Michael Albinus addressed - in an email that seems to
> be stuck in the mailing list flow somewhere - where he wrote:
>
>     GET /projects/<id>/issues?scope=all&updated_after=2019-11-19T13:22:55.640Z
>
>     <id> is your project id.
>
>     Best regards, Michael.
>
> That might be useful?

Yup, that's a good API call for Gnus to use.

> I *am* worried about ending up with yet-another-nnslashdot backend,
> which is so dog slow that it is unusable...

Yeah, that's what I was thinking of, too.  At first people are like
"yay, Slashdot in Gnus" and then two days later "oh, the slowness; I'd
rather not ever read Slashdot ever again".

> Alternatively I could build a "gitlab_to_nntpd", but I think the
> integration (especially with changing labels and status by editing
> articles, rather than superseding), would be easier/better if it is a
> backend that Gnus knows that editing directly works for?

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2019-11-19 22:11 Gnus backend for GitHub/GitLab? Adam Sjøgren
                   ` (2 preceding siblings ...)
  2019-11-20 11:33 ` Lars Ingebrigtsen
@ 2020-01-14 20:42 ` Adam Sjøgren
  2020-01-14 21:23   ` dick
  3 siblings, 1 reply; 15+ messages in thread
From: Adam Sjøgren @ 2020-01-14 20:42 UTC (permalink / raw)
  To: ding

Adam writes:

> It hit me that accessing comments on GitHub/GitLab seems like an obvious
> candidate for a Gnus backend.
>
>   * GitHub/GitLab-instance: a Gnus server
>   * Each project you're interested in: a subscribed group
>   * Each issue: a top-level article
>   * Each comment: replies to issues/other comments
>   * Label, State ...: headers that can be edited

So, I have gotten a little further on this - I have some code that
allows me to list projects as groups in Gnus, and to show issues of a
project as articles in a summary.

It's fairly straight forward (using ghub.el).

However, there is a snag.

I *really* like the mapping sketched out above, where each GitLab
project maps to a newsgroup, and each issue/comment maps to an article/a
follow up.

But... the numbering. GitLab numbers issues within a project 1, 2, 3,
... - as you, and a newsgroup, would expect.

However, comments on an issue are numbered 1, 2, 3, ...

Whoops. I would like them to be follow ups _in the same group_. So they
need to map to article numbers in the same group.

Ouch.

Any good ideas on how to handle this?

My first thought was "oh, just add a billion to the global comment id",
but I seem to remember that newsreaders aren't really happy about huge
gaps, and you wouldn't know when new issues arrived, only when new
comments did.

I could have a group per issue, which holds the comments, but that's
also a major mismatch with the newsreader-model.

I can't see any good solution :-/


  Best regards,

    Adam

-- 
 "More than anything, I won't try"                          Adam Sjøgren
                                                       asjo@koldfront.dk




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-14 20:42 ` Adam Sjøgren
@ 2020-01-14 21:23   ` dick
  2020-01-14 22:03     ` Adam Sjøgren
  0 siblings, 1 reply; 15+ messages in thread
From: dick @ 2020-01-14 21:23 UTC (permalink / raw)
  To: ding

I don't understand your "add a billion" comment.

It's unimportant how gitlab numbers messages.  I've written gnus backends
whose messages are keyed off non-numeric strings.  Gitlab merely needs to
provide the parent issue id for each incoming child comment.  Then I'd
write a suitable  nngitlab-retrieve-headers that spits out the
parent id in the `References` header.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-14 21:23   ` dick
@ 2020-01-14 22:03     ` Adam Sjøgren
  2020-01-14 22:18       ` dick
  0 siblings, 1 reply; 15+ messages in thread
From: Adam Sjøgren @ 2020-01-14 22:03 UTC (permalink / raw)
  To: ding

dick writes:

> It's unimportant how gitlab numbers messages.

I don't understand how it is? At the very least Gnus needs the ids to
get the information about each issue/comment from the API.

> I've written gnus backends whose messages are keyed off non-numeric
> strings.

Do you have any examples online I can look at?

> Gitlab merely needs to provide the parent issue id for each incoming
> child comment. Then I'd write a suitable nngitlab-retrieve-headers
> that spits out the parent id in the `References` header.

How would you map issues and comments to article numbers?

Let's say you have a project team/project as a group team.project. It
has 4 issues with 4, 2, 0 and 1 comments each:

  issue 1
    comment 1
    comment 2
    comment 3
    comment 4
  issue 2
    comment 1
    comment 2
  issue 3
  issue 4
    comment 1

As far as I can see, these need to be mapped to article numbers, so Gnus
can get information about max number and min number for the group, and
to retrieve articles by number.

How do you construct a mapping that allows new comments and issues to
arrive, and keeps no state, using only the GitLab API?


  Best regards,

    Adam

-- 
 "6666 - extra evil"                                        Adam Sjøgren
                                                       asjo@koldfront.dk




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-14 22:03     ` Adam Sjøgren
@ 2020-01-14 22:18       ` dick
  2020-01-14 22:45         ` Adam Sjøgren
  0 siblings, 1 reply; 15+ messages in thread
From: dick @ 2020-01-14 22:18 UTC (permalink / raw)
  To: ding

AS> As far as I can see, these need to be mapped to article numbers, so Gnus
AS> can get information about max number and min number for the group, and to
AS> retrieve articles by number.

Yes, absolutely, your backend needs to sequentially number articles (which in
this context are issues/comments).

But that numbering is one of your own making, not gitlab's.

AS> How do you construct a mapping that allows new comments and issues to
AS> arrive, and keeps no state, using only the GitLab API?

I keep an array of articles (to go from our numbering to the issue/comment).
And I maintain a hashtable to go from gitlab's arbitrary id to our numbering.

Is there a requirement to keep no state?  I need to at least persist state for
.newsrc.eld to keep track of what has and hasn't been read and seen (yes,
there's a difference in Gnus between "read" and "seen").




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-14 22:18       ` dick
@ 2020-01-14 22:45         ` Adam Sjøgren
  2020-01-15  4:47           ` dick
  0 siblings, 1 reply; 15+ messages in thread
From: Adam Sjøgren @ 2020-01-14 22:45 UTC (permalink / raw)
  To: ding

dick writes:

> AS> As far as I can see, these need to be mapped to article numbers, so Gnus
> AS> can get information about max number and min number for the group, and to
> AS> retrieve articles by number.
>
> Yes, absolutely, your backend needs to sequentially number articles (which in
> this context are issues/comments).
>
> But that numbering is one of your own making, not gitlab's.

Yes, that's pretty much exactly what I wrote.

> I keep an array of articles (to go from our numbering to the issue/comment).
> And I maintain a hashtable to go from gitlab's arbitrary id to our numbering.

It sounds like you've already implemented nngitlab, is this something
you care to share?

> Is there a requirement to keep no state?

I would prefer the backend only depend on the API - and of course Gnus
will do whatever it usually does with state.

> I need to at least persist state for .newsrc.eld to keep track of what
> has and hasn't been read and seen (yes, there's a difference in Gnus
> between "read" and "seen").

This is something Gnus keeps track of generally, not something that a
new backend needs to concern itself with, right?

So besides what Gnus usually does, you keep state about your mapping
between GitLab's ids and article numbers - where do you keep that state,
inside .newsrc.eld or in a separate file?


  Best regards,

    Adam

-- 
 "What would you like to drink?" "Formaldehyde."            Adam Sjøgren
 "Straight or on the rocks?"                           asjo@koldfront.dk




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-14 22:45         ` Adam Sjøgren
@ 2020-01-15  4:47           ` dick
  2020-03-17 11:03             ` dick.r.chiang
  0 siblings, 1 reply; 15+ messages in thread
From: dick @ 2020-01-15  4:47 UTC (permalink / raw)
  To: ding

AS> It sounds like you've already implemented nngitlab, is this something you
AS> care to share?

I've implemented backends for Reddit and Hacker News.  You can find them in
github.com/dickmao/{nnreddit,nnhackernews}.

AS> So besides what Gnus usually does, you keep state about your mapping
AS> between GitLab's ids and article numbers - where do you keep that state,
AS> inside .newsrc.eld or in a separate file?

I keep it in memory.  By following Gnus Info Section 11.6.2 "Back End
Interface", implementing certain methods causes Gnus core to persist state in
.newsrc.eld automatically.

I am a tad skeptical about github's amenability to a Gnus backend
implementation.  You'd know better than I if their API can answer "give me all
the new messages since the last id I saw".  Both Reddit and Hacker News can
answer this.  I looked at the ghub-get call in Mr. Bernoulli's forge-github.el
and it seems to only do a RESTful query of "/notifications", which is not
quite stateful enough.

In truth I am rather content with github's existing notifications mechanism that
sends normal mail (which Gnus's basic filtering dutifully routes) for issues
I've commented on, and for repos I've self-designated "watched."  Gnus-ifying
github would be very nice, and you should press onwards, but I already get
"just show me new comments" which I couldn't get from the Reddit and Hacker News websites
(but I do now with nnreddit and nnhackernews).

I started (but currently am not) working on a backend for the Discourse API.
In particular, I want to gnus-ify emacs-china.org, which like Reddit and
Hacker News, really lends itself to this treatment.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Gnus backend for GitHub/GitLab?
  2020-01-15  4:47           ` dick
@ 2020-03-17 11:03             ` dick.r.chiang
  0 siblings, 0 replies; 15+ messages in thread
From: dick.r.chiang @ 2020-03-17 11:03 UTC (permalink / raw)
  To: ding

d> I started (but currently am not) working on a backend for the Discourse

Well, I published the backend for Discourse on MELPA.  I use it to follow
emacs-china.org, but any Discourse URL is supposed to work.


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-19 22:11 Gnus backend for GitHub/GitLab? Adam Sjøgren
2019-11-20  3:31 ` Eric Abrahamsen
2019-11-20  4:12 ` dick.r.chiang
2019-11-20 11:33 ` Lars Ingebrigtsen
2019-11-20 12:38   ` Adam Sjøgren
     [not found]     ` <87h82ywu6i.fsf@gmx.de>
2019-11-20 15:01       ` Adam Sjøgren
     [not found]         ` <87h82yvb7r.fsf@gmx.de>
2019-11-20 15:35           ` Adam Sjøgren
2019-11-21 12:31     ` Lars Ingebrigtsen
2020-01-14 20:42 ` Adam Sjøgren
2020-01-14 21:23   ` dick
2020-01-14 22:03     ` Adam Sjøgren
2020-01-14 22:18       ` dick
2020-01-14 22:45         ` Adam Sjøgren
2020-01-15  4:47           ` dick
2020-03-17 11:03             ` dick.r.chiang

Gnus development mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/ding

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.emacs.gnus.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git