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).