[Sorry for having dropped this thread on the floor for a while.]
On Tue, Jan 16, 2018 at 09:32:25PM -0800, Barry Warsaw wrote:
I'm experimenting with a port of Launchpad's mailing list infrastructure to Mailman 3. If Barry's reading, he may remember that this is no trivial task, so I'm very definitely not promising that it will be done any time soon. :-) [...] I’m proud that the mailing list feature of Launchpad eventually became
On Jan 14, 2018, at 09:45, Colin Watson <cjwatson@ubuntu.com> wrote: pretty darn solid, with much credit to Colin, Curtis Hovey, and many of my other wonderful former colleagues on the Launchpad team and at Canonical.
Shoulders of giants and all that. :-)
However, for the most part it looks relatively tractable with the aid of the plugin improvements in Mailman 3.2.0; I have the rough outline of a plugin that implements much the same feature set as our current pile of monkey-patches against Mailman 2.1 in a much nicer way.
Very cool!
You’ve provided some clarification in a follow up, and I’ll respond there. Apologies for being a little disjointed.
One of the things that may really help you, but which doesn’t exist in a fully baked way in Core is the ability to set web hooks for various events. Core does have an event notification system (via zope.events) and that’s used to inform other parts of the Core about things like subscriptions/unsubscriptions, etc. Where web hooks would be useful is if some event in Core needs to inform Launchpad of that event.
Web hooks might be interesting to look at (if they were fully baked, of course), but I'd have some reservations. The problem with that approach is that it tends to be "fire and forget", and in particular if one part of the system is down or temporarily unreachable or whatever then state can get out of sync. I think it would be unfortunate to end up with a system where a user could end up inconsistently subscribed in multiple databases due to a temporary network partition, and we might never notice.
IME web hooks work better in situations where their state is visible and it's easy for somebody to redispatch them if they seem to have got lost. GitHub's integration with various third-party services like Travis is a good example.
For this reason, I usually favour "catch-up" approaches where one service asks another for all the events that have happened since a particular date (if it isn't just asking the other service for information synchronously, of course). I suppose this is what people call "eventually consistent". And in any case I think in our system events are generally going to flow from Launchpad to Mailman rather than the other way round. So, rather than notifications, I'd been planning to stick with something broadly along the lines of how Launchpad's Mailman 2 integration works: we have a runner in the Mailman plugin that talks to a Launchpad API that publishes a sequence of pending actions, and consumes those to keep itself up to date. It may be a bit clunky, but it's essentially robust.
Alternatively, we could schedule jobs in Launchpad's own job queuing system any time a relevant event (new list, subscription, etc.) happens, and have those talk to Mailman's REST API with a backoff-and-retry arrangement. Maybe that'd be easier.
Ideally, I'd like mailing lists to have a "deactivated" state in addition to full deletion. In this state, the list would appear nonexistent for most purposes: incoming email would be rejected,
I forget whether LP uses Exim or Postfix.
I ... am actually not 100% sure. But a Mailman 3 migration would involve a complete redeployment of the mailing list components on cloud instances anyway, so we're not bound to what we have at the moment.
At least for the latter, it would be fairly easy (if involving a database migration) to include an “active” or “enabled” flag which would be consulted when regenerating the Postfix transport files. I would add this to the MailingList model and make it available through the REST API. Then the LP team admin can toggle this on and off as desired.
Yes, something like that. Though maybe we could just change its posting chain to 'reject' or similar with a "this list is closed" message instead, and dispense with the need for an explicit enabled flag?
-- Colin Watson [cjwatson@ubuntu.com]