Date: Wed, 20 Mar 2019 00:05:51 -0400
From: Drew DeVault <sir@cmpwn.com>
To: alpine-devel@lists.alpinelinux.org
Cc: alpine-infra@lists.alpinelinux.org
Subject: [alpine-devel] Improving Alpine Linux's email stack
Message-ID: <20190320040551.GA2283@homura.localdomain>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

There was some discussion about this on IRC last night, but I had an
event to attend so we decided to take it to the ML. Here's a summary of
the issue(s) and possible solutions.

As a reminder, the current Alpine mail stack is based on mlmmj[0] for
handling & forwarding incoming mail, and hypermail[1] for web archives.
At some point there seems to have been swish-e for searching the
archives, but both the swish-e project and Alpine's deployment of it
seem to be now defunct.

[0] http://mlmmj.org/
[1] http://www.hypermail-project.org/

The main issues with mlmmj are:

- It strips out In-Reply-To headers when forwarding mail, which breaks
  threading
- It modifies emails a lot in general, which breaks DKIM signatures and
  will trip a lot of spam filters up

Hypermail's main issues are:

- No search functionality
- No way to download original messages or anything else you can feed to
  git am

The last one is addressed to some extent by patchworks, but patchworks
also doesn't have a search et al. I've found it difficult, for example,
to obtain the original message for patches older than a few months.

Solutions:

Many of you know that I have a conflict of interest, as I maintain
lists.sr.ht, an open source mailing list driver, archive, and hosted
service. Take the following with the requisite grain of salt, as it's
basically an ad.

lists.sr.ht is free & open source software[0] (AGPL) and can be hosted
on Alpine infrastructure, though you're welcome to use my hosted service
for experimentation and/or production uses. I have a mirror of the
aports list here[1], though threading is currently broken because of the
issues with mlmmj. Here's[2] a list where threading does work, if you
want to peruse the archives.

[0] https://git.sr.ht/~sircmpwn/lists.sr.ht
[1] https://lists.sr.ht/~sircmpwn/alpine-aports
[2] https://lists.sr.ht/~sircmpwn/sr.ht-dev

Advantages: there's no delay between emails arriving and being available
on the web archives. Emails are already grouped into threads and
organized by the last thread updated, and there's a powerful search tool
that you can use to find emails which are patches, are written by or Cc
certain people, have certain email headers, and so on. There's also an
API:

https://man.sr.ht/lists.sr.ht/api.md

Patches are given special treatment on the archive, with patchworks-like
highlighting, links to specific lines & files, and so on:

https://lists.sr.ht/~sircmpwn/alpine-aports/%3C20190312025245.20168-1-sir%40cmpwn.com%3E

A gerrit-like interface for doing patch review on the web or via email
is planned to be implemented within the next few months, at least in its
basic form - which should provide a nice alternative to patchworks.
Another benefit is planned integration with builds.sr.ht, my CI
platform, which will be available within a few weeks and will allow for
CI across all architectures supported by Alpine for all patches sent to
the mailing list - and to GitHub, too, if you like. A similar
integration with git.sr.ht (which hosts git repositories) will allow you
to keep track of patches which have and have not yet been merged
automatically, as well as getting back to the mailing list discussion
from a commit in the git UI.

I also have first-class Alpine Linux support, as all of the hosted
infrastructure runs on Alpine Linux. I have a CI which automatically
publishes packages for *.sr.ht to my third-party apk repository:

https://mirror.sr.ht/alpine/sr.ht/

I can set up the CI stuff, and to some extent code review, with another
mail driver. GNU mailman would be a common choice. I think that
lists.sr.ht is a compelling option, though, and I would be happy to
answer questions and provide support - even if you don't choose
lists.sr.ht. I depend on Alpine Linux a lot and I'm eager to give back
in any way I can.

--
Drew DeVault


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---