I did a fair bit more updating of the old list information web page for each of the BALUG-Admin and BALUG-Talk web pages. Notably removed is the information about and the posting address, and likewise subscribe information. Also added information and link to new location, etc. Did retain portions to unsubscribe or edit options, view subscribers list (which will work for non-listadmin members if the list permissions allow such).

Though it could be argued, could keep old location also "active" until it's quite fully killed off, I quite prefer the simplicity of the old location being effectively "read-only". Notably it avoids the work/complications/confusion of: o no need to have yet other messages to merge into archive o no interleaved merging of messages to preserve chronological order when merging into archive (e.g. bunch of stuff to both old and new overlapping in time) o reduce member confusion about "which list", and why am I (or might I) be seeing this on both? o eliminate posters double-posting to both lists o thwart issues such as hot explosive topic with flurry of replies, etc. on old list location Anyway, whole lot 'o potentially issues are cut off by making old location effectively "read-only".

Glitch free? Almost. No glitches visible to users in the migration - all according to plan. The only slight glitch I bumped into - but worked around manually easily enough - non-ASCII character(s) in members' full names. (to manually work-around, I loaded that setting for that member with slightly different full name, then used listadmin to go to their preference page, and did copy-paste of that one field from old to new to get it as the member had set it). Hit exactly one of those on migrating BALUG-Talk. My programs caught that in the verification phase or thereabouts - notably failed to set target to match as expected. Anyway, I should have that further tested (on the BALUG-Test list, of course) and fixed before migrating the BALUG-Announce list. I did earlier test quite fully fine with all isprint() ASCII characters (though I may not have tested/validated leading or trailing spaces). Anyway, wee bit 'o tweak to the encode/decode bits of the code, and should then handle the non-ASCII without further issue.

And yes, in the earlier testing, had, on/for BALUG-Test list, locally created 1,000 email aliases - with mixed case in the localpart of the email addresse, mass subscribed them case preserved, randomly set member's binary options - except set the disable mail on all of them, set their full names on each to match their case preserved localpart, various mass changing via program of their options (e.g. flipping all the binary options except disable mail), etc. Anyway, all that earlier testing went fine (after I'd also earlier updated to handle proper handling of all isprint() ASCII).