>>>>> "LN" == Les Niles <[EMAIL PROTECTED]> writes:
LN> There's a small bug in 2.1alpha4 in updating a list's database
LN> to the DATA_FILE_VERSION, causing "nomail" settings to not be
LN> propagated forward:
LN> MailList.CheckVersion() reloads the database, taking care to
LN> make sure that the reload doesn't trigger a recursive call to
LN> CheckVersion(). But if the list wasn't locked, CheckVersion()
LN> then calls Lock(), and Lock() calls Load() again, this time
LN> generating a recursive call to CheckVersion(). This recursion
LN> is only one deep because now the list is locked, but even that
LN> is too much for versions.CanonicalizeUserOptions() since it
LN> clears the old-style "nomail" flag after setting the delivery
LN> status in the new database.
I need more help with this one because I cannot reproduce the
problem. I've tried taking a MM2.0.8 list, with some members delivery
disabled, and done upgrades to cvs. I've tried loading the list in
its locked and unlocked state. In every case I see the disabled flag
propagate to the updated list. Of course, the member management page
shows the reason for disabled as [?] which is correct.
I have a tentative patch to versions.py that at least stops
CanonicalizeUserOptions() from running more than once. But I can't
judge the correctness of Les's patch unless I have a reproducible
bug. So if you have some explicit steps to trigger the bug, please
send them on, otherwise, I can't do much about this.
If it's a real bug, I'm sure it will come up during beta testing, but
that might be too late (i.e. it might bite badly for people who are,
er, more enthusiastic about upgrading. ;).
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
