And yes, tested, for the target Mailman, list admin can alter the relevant member's options just fine via the web GUI ... so ...
Have what should be sure-fire method now (and eliminates unknown bit about how long it would take for me to figure out method via Python pickle (.pck) or similar CLI interface method) - and it will also include verification.
So, with that, I'm guestimating I'll likely do the first *for real* list migration sometime today or tomorrow (after writing additional relevant code, and quite full testing, etc.).
Don't think I'll have all the lists migrated by end-of-month (I think that was somewhat earlier target timeline), but I'm thinking all the lists would be migrated* within 5 to 10 days from now.
*well, will take a bit longer to get mbox archives from DreamHost.com - presuming we can get 'em to cough 'em up.
Some other fairly smallish and relatively easy bits to cover after that to fully extricate ourselves from DreamHost.com ... but getting rather close now. Can almost taste it. :-) Yes, freedom is good!
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: List migrations and preserving options as feasible - another approach ... WWW::Mechanize to load! Date: Sun, 30 Jul 2017 12:22:18 -0700
Not sure why I didn't think of it earlier (perhaps it wasn't quite as obvious earlier), but another approach which may be highly feasible ... use WWW::Mechanize to load options! So, ... presuming it's fully workable (list admin can load? - need to test that), if that bit is doable - notably list admin can load/edit member's options on the individual members' options page, then that ought be fairly straight forward (moderate extension of what I've already coded to gather the options) - would also have key verification advantage - can (reload and) inspect target page after to ensure options match as expected (programmatically* of course). But I notice list admin can't make *some* member changes (e.g. disallows list admin to change member's password ... at least one Mailman version I looked at) - but setting that isn't an issue/concern - it's all the other options. Anyway, in theory (presuming the relevant tests work), could go quite something like this: "disable" old list (set "emergency" moderation, update description regarding migration - effectively leave old location read-only) scrape source data stop exim (so that member settings will be suitably adjusted before they're notified of subscription having been migrated) subscribe members - preserving email case (as user subscribed**) tweak user's options (using the scraped data, and also verifying results), restart exim
*dang, I have to resort to american-english-huge before programmatically passes the spell(1) check.
**I also notice Mailman (at least one version I checked) doesn't let user's change their email address to another version of same email address but only with changes in case - it complains that they're already subscribed/member - or something to that effect. Now, I could see requiring email verification if case of localpart changes (as they *could* be distinct addresses/recipients), but seems Mailman ought handle that same way it does for user making any other change to their email address.
Anyway, presuming it works, may well get me to the needed load functionality more quickly than the Python pickle (.pck) route or the like - plus has the verification advantage.
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: lot of really nice command-line tools to use in dumping and editing various pck databases Date: Sun, 30 Jul 2017 11:55:20 -0700
Thanks, slick, noted.
I also noticed there's package (mailman-api)for a REST API for Mailman. I also found a very promising mmclient (which uses Mailman's REST API), but alas, don't see a corresponding package by Debian.
Also thought of something else highly practical ... but, topic drift, will post that separately.