[Mailman-Developers] Misc thoughs on 2.0.5ish to 2.1b1

[Ron Jarrell]

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