Upgrading my production server... I'm amazed I didn't notice some of this stuff on my test server, although that might be the fact that this big a jump has side effects that regular cvs updates didn't, (since update didn't necessarily do some things if I let it run before it knew how to do something, I suspect), or maybe the fact that my test lists are basically *me* in a variety of configurations, or maybe I'm just suddenly hitting bugs..

The upgrade process really ought not fill the errors log during the update process with "database for list whatever is corrupt, falling back to (whatever)"...

Was the site password supposed to die? I can't remember if that happened to me during the various cvs upgrades I've done.

The site password, once fixed, no longer works the same way when used as a trump password. For instance, *just* using the site password (and any old string under "email address") could get me into archives, listinfo screens, subscriber lists, etc. Now it seems I have to explicitly know an address that's subscribed to the list to use the sitepass - which is particularly annoying when I'm testing a new list that doesn't *have* subscribers on it! I'd rather the test be "(valid address and pass) OR site pass" not "valid address and (valid pass or site pass)" like it used to be...

***THE UPGRADE REALLY OUGHT NOT PUT IN THE "There are not messages in the archive" HOLDER URL FOR LISTS THAT *HAVE* THINGS IN THE ARCHIVE ALREADY!!**

The above scared the (#($*# out of me...

Having now had to use a list that had more than 2 test users on it, I agree with the comments made earlier - the new alphabetical subdivision system is a royal pain. I'm getting just 4-5 users at a time, and have to click as many as 28 times to quickly scan my users to see, for instance, who's in nomail, whereas before it was at most 4-5 chunks. Allowing an optional "just show me a chunk worth" is *well* worth it for convenience sake. Or just let the regexp display show them by chunks.. (I was really hoping that it would, but no, it just broke them down by alphabet when it got to be too many again...)

For "new" flags, like "nodupes", when converting users, shouldn't we apply the current default user flag mask? With the default 256, no old users will have nodupes set, but all new users will...

I'm sure I'll think of more :-)