From barry at list.org Mon Aug 4 15:13:06 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 4 Aug 2008 09:13:06 -0400 Subject: [Mailman-Developers] Scheduled downtime for wiki.list.org Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, Just a quick note that Contegix, our hosting provider for the wiki, will be performing a requested upgrade of the server at 0200 EDT on Tuesday, August 5. There is a 2 hour planned downtime for the upgrade. No other Mailman services will be affected. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiXAGQACgkQ2YZpQepbvXGqmQCcCMBn0D5lDTm2e/p066PjMwBN NFIAoJ7B/gzfWGqcNEe0lZOP1o8UbA29 =HCPy -----END PGP SIGNATURE----- From Max.Lanfranconi at Sun.COM Tue Aug 5 17:39:31 2008 From: Max.Lanfranconi at Sun.COM (Max Lanfranconi) Date: Tue, 05 Aug 2008 08:39:31 -0700 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly "disappear" In-Reply-To: <20080805151836.28DEA174F9@britaine.cis.anl.gov> References: <20080805151836.28DEA174F9@britaine.cis.anl.gov> Message-ID: <48987433.7030404@sun.com> I tried the "sleep" approach as well. But then I thought that it was not viable. I am setting a relatively high number of mailing list that will receive asynchronous "subscribe" requests via web and/or shell API. It would be simply not possible to prevent bug this from happening as the chance of two "subscribe" being processsed almost simultaneously are not that small... I also vote for some kind of timing/lock issue. Max Barry Finkel wrote: > Max Lanfranconi wrote: > > >> Mailman 2.1.11 >> Python 2.4.4 >> OS Solaris 2.11 >> >> >> Hi, >> >> I have been able to reproduce this bug consistently by running the >> replicate_bug script: >> >> >> replicate _bug is the following: >> >> #!/bin/sh >> /usr/local/mailman/bin/rmlist testlist1 >> /usr/local/mailman/bin/rmlist testlist2 >> /usr/local/mailman/bin/rmlist testlist3 >> /usr/local/mailman/bin/rmlist testlist4 >> /usr/local/mailman/bin/rmlist testlist5 >> /usr/local/mailman/bin/rmlist testlist6 >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist1 >> list-admin at domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist2 >> list-admin at domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist3 >> list-admin at domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist4 >> list-admin at domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist5 >> list-admin at domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist6 >> list-admin at domain.com testpwd >> >> >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "foo at bar.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "boo at foo.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> >> After a short wait the following output is received: >> >> Subscribed: foo at bar.com >> Subscribed: foo at bar.com >> Subscribed: foo at bar.com >> Subscribed: foo at bar.com >> Subscribed: foo at bar.com >> Subscribed: foo at bar.com >> Subscribed: boo at foo.com >> Subscribed: boo at foo.com >> Subscribed: boo at foo.com >> Subscribed: boo at foo.com >> Subscribed: boo at foo.com >> Subscribed: boo at foo.com >> >> foo at bar.com receives 6 confirmation emails, as boo at foo.com does. S >> o far so >> good. >> >> At this point testlist1-6 each should contain 2 subscribers: foo at bar.com >> and boo at foo.com >> >> BUT >> >> /usr/local/mailman/bin/list_members testlist1 >> /usr/local/mailman/bin/list_members testlist2 >> /usr/local/mailman/bin/list_members testlist3 >> /usr/local/mailman/bin/list_members testlist4 >> /usr/local/mailman/bin/list_members testlist5 >> /usr/local/mailman/bin/list_members testlist6 >> >> invariably produce some random combination in which one or more of the >> subscribers are missing: >> for example: >> boo at foo.com >> foo at bar.com >> foo at bar.com >> boo at foo.com >> foo at bar.com >> foo at bar.com >> foo at bar.com >> boo at foo.com >> foo at bar.com >> >> in which three instances of boo at foo.com are missing... >> >> No Errors in any Mailman log. >> >> >> Thanks in advance for your help. Please let me know if you need additional >> details. >> Regards, >> Max >> > > I ran the script (after some minor modifications) on > > Ubuntu Dapper > Mailman 2.1.11 (self-built package) > Python 2.4.3 (#2, Oct 6 2006, 07:49:22) > > and I get similar results: > > Script started on Tue 05 Aug 2008 09:45:31 AM CDT > # set prompt="mailman11-test# " > mailman11-test# ./replicate_bug.exec > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist1 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist2 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist3 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist4 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist5 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist6 > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo at foo.com > foo at bar.com > 2 > boo at foo.com > foo at bar.com > 3 > boo at foo.com > foo at bar.com > 4 > boo at foo.com > foo at bar.com > 5 > foo at bar.com > 6 > foo at bar.com > mailman11-test# ======================================================= > mailman11-test# ./replicate_bug.exec > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo at foo.com > foo at bar.com > 2 > boo at foo.com > foo at bar.com > 3 > foo at bar.com > 4 > foo at bar.com > 5 > foo at bar.com > 6 > foo at bar.com > mailman11-test# ======================================================= > mailman11-test# ./replicate_bug.exec > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: foo at bar.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > Subscribed: boo at foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > foo at bar.com > 2 > boo at foo.com > foo at bar.com > 3 > foo at bar.com > 4 > foo at bar.com > 5 > foo at bar.com > 6 > foo at bar.com > mailman11-test# exit > > Script done on Tue 05 Aug 2008 09:50:48 AM CDT > > I then added > > sleep 5 > > after each "add_members" line, and the output looked fine. > I changed the sleep interval from 5 down to 1 in successive > runs, and each output looks fine; each list has the proper two > subscribers. Is there a timing issue here? > ---------------------------------------------------------------------- > Barry S. Finkel > Computing and Information Systems Division > Argonne National Laboratory Phone: +1 (630) 252-7277 > 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 > Building 222, Room D209 Internet: BSFinkel at anl.gov > Argonne, IL 60439-4828 IBMMAIL: I1004994 > > ------------------------------------------------------ > Mailman-Users mailing list > Mailman-Users at python.org > http://mail.python.org/mailman/listinfo/mailman-users > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-users/max.lanfranconi%40sun.com > > Security Policy: http://wiki.list.org/x/QIA9 > From mark at msapiro.net Wed Aug 6 01:34:24 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 5 Aug 2008 16:34:24 -0700 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: <48987433.7030404@sun.com> Message-ID: Max Lanfranconi wrote: >I tried the "sleep" approach as well. But then I thought that it was not >viable. >I am setting a relatively high number of mailing list that will receive >asynchronous "subscribe" requests via web and/or shell API. > >It would be simply not possible to prevent bug this from happening as >the chance of two "subscribe" being processsed almost simultaneously are >not that small... > >I also vote for some kind of timing/lock issue. Based on my running of the test script (see , with LIST_LOCK_DEBUGGING = True I think I see the problem. It is related to qrunner list caching and the fact the there is insufficient precision in the list instance's __timestamp The scenario is the following 1) add_member saves the list with the first member. 2) VirginRunner gets there first, instantiates and caches the list. It then locks the list, processes the welcome and saves and unlocks the list. 3) add_member gets the lock, adds the second member and saves the list. 4) Virgin runner gets the second welcome. The list is cached, so it uses the cached instance. It then locks the list which ultimately calls MailList.__load() to refresh the list data, but __load() does mtime = os.path.getmtime(dbfile) if mtime <= self.__timestamp: # File is not newer return None, None The problem is os.path.getmtime() returns a time in seconds so if we are still in the same second as step 2), we don't refresh the list. Thank you very much Max for providing a script to reproduce the problem. I'm not sure of the best solution. I'm leaning towards dropping the __timestamp test or perhaps replacing it with a file size test, but that too may be unreliable. Other thoughts? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Wed Aug 6 03:08:33 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 06 Aug 2008 10:08:33 +0900 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: References: <48987433.7030404@sun.com> Message-ID: <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> Mark Sapiro writes: > 1) add_member saves the list with the first member. > 2) VirginRunner gets there first, instantiates and caches the list. > It then locks the list, processes the welcome and saves and unlocks > the list. > 3) add_member gets the lock, adds the second member and saves the list. > 4) Virgin runner gets the second welcome. The list is cached, so it > uses the cached instance. It then locks the list which ultimately > calls MailList.__load() to refresh the list data, but __load() > does > > mtime = os.path.getmtime(dbfile) > if mtime <= self.__timestamp: > # File is not newer > return None, None Shouldn't "mtime < self.__timestamp" do the right thing (much more often)? You're still vulnerable to "date -s", adjtime, and friends, though, and of course you'll have some undesirable cache misses at times when it would be nice if you didn't. A better way would be to add a serial number. From barry at list.org Wed Aug 6 03:13:07 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 5 Aug 2008 21:13:07 -0400 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2008, at 7:34 PM, Mark Sapiro wrote: > > I think I see the problem. It is related to qrunner list caching and > the fact the there is insufficient precision in the list instance's > __timestamp > > The scenario is the following > > 1) add_member saves the list with the first member. > 2) VirginRunner gets there first, instantiates and caches the list. > It then locks the list, processes the welcome and saves and unlocks > the list. > 3) add_member gets the lock, adds the second member and saves the > list. > 4) Virgin runner gets the second welcome. The list is cached, so it > uses the cached instance. It then locks the list which ultimately > calls MailList.__load() to refresh the list data, but __load() > does > > mtime = os.path.getmtime(dbfile) > if mtime <= self.__timestamp: > # File is not newer > return None, None > > The problem is os.path.getmtime() returns a time in seconds so if > we are still in the same second as step 2), we don't refresh the > list. > > Thank you very much Max for providing a script to reproduce the > problem. > > I'm not sure of the best solution. I'm leaning towards dropping the > __timestamp test or perhaps replacing it with a file size test, but > that too may be unreliable. I wonder if the list cache is still worth it? I've run into trouble with it in the recent past and I suspect that whatever benefits we got from it in ancient times, may not be so relevant today. My first inclination would be to ditch the cache, but that may not completely solve this issue (ah, for the backing of a real database!). Ultimately the timestamp check probably has to go. If we try to load the list, we should just load it and not try to be so fancy to avoid reading from disk. Yes, it means more I/O but reliability is more important, IMO. I'm not convinced a size check is worth it. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiY+qMACgkQ2YZpQepbvXHUbgCfeWIwkAjv/9wYpJa9vQ16dwCP jYIAn0wVNl3JXm+9R2LJ5AUa46FwhNAN =P5Yo -----END PGP SIGNATURE----- From barry at list.org Wed Aug 6 03:15:20 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 5 Aug 2008 21:15:20 -0400 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> References: <48987433.7030404@sun.com> <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <26B37011-6CD5-44B9-A0C2-86B58B78D65A@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2008, at 9:08 PM, Stephen J. Turnbull wrote: > Mark Sapiro writes: > >> 1) add_member saves the list with the first member. >> 2) VirginRunner gets there first, instantiates and caches the list. >> It then locks the list, processes the welcome and saves and unlocks >> the list. >> 3) add_member gets the lock, adds the second member and saves the >> list. >> 4) Virgin runner gets the second welcome. The list is cached, so it >> uses the cached instance. It then locks the list which ultimately >> calls MailList.__load() to refresh the list data, but __load() >> does >> >> mtime = os.path.getmtime(dbfile) >> if mtime <= self.__timestamp: >> # File is not newer >> return None, None > > Shouldn't "mtime < self.__timestamp" do the right thing (much more > often)? You're still vulnerable to "date -s", adjtime, and friends, > though, and of course you'll have some undesirable cache misses at > times when it would be nice if you didn't. Probably so, but is the optimization still worth it? > A better way would be to add a serial number. You'd probably want to store the serial number in the file name so you wouldn't have to load the pickle just to get the current serial. It's similar to what happens with the queue files. But again, I'm not sure it's worth it. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiY+ygACgkQ2YZpQepbvXHdBwCfZRO73w4KiA0FMg6eU3yDU8YN Y7AAoLE5760wZWw536oMj1zyHMNi8h4a =w1PV -----END PGP SIGNATURE----- From mark at msapiro.net Wed Aug 6 03:26:36 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 5 Aug 2008 18:26:36 -0700 Subject: [Mailman-Developers] [Mailman-Users] Subscriberssuddenly"disappear" In-Reply-To: <4898F804.40105@sun.com> Message-ID: Massimo Lanfranconi wrote: > >I am more than willing to try any workaround as this bug is currently a >showstopper for my project. >I am not very versed in mailman internals, so I need some guidance here. > >Do you recommend I try getting rid of the __timestamp test and give it >a try ? Yes. >If that is you suggestion, may I ask what was the original purpose of >that test ? Lots of Mailman processes will instantiate a list unlocked for some preliminary checks and then later, lock the list to do some update. The purpose of the timestamp test was to avoid rereading the list data from the config.pck file if the already loaded data is still current. What I suggest for the moment is to just delete lines 594-603 of Mailman/MailList.py which includes the following 4 lines and the preceding comment. >> mtime = os.path.getmtime(dbfile) >> if mtime <= self.__timestamp: >> # File is not newer >> return None, None This will result in some additional I/O in some cases, but it will avoid this problem of sometimes not loading the list data when it has actually changed. Please do that and restart Mailman and I'm sure the bug will be fixed (but don't take my word for it). -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From amk at amk.ca Wed Aug 6 03:50:19 2008 From: amk at amk.ca (A.M. Kuchling) Date: Tue, 5 Aug 2008 21:50:19 -0400 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: References: Message-ID: <20080806015019.GA14859@amk.local> On Tue, Aug 05, 2008 at 09:13:07PM -0400, Barry Warsaw wrote: > I wonder if the list cache is still worth it? I've run into trouble > with it in the recent past and I suspect that whatever benefits we got > from it in ancient times, may not be so relevant today. My first I expect cPickle or even pickle are pretty fast, and the config.pck is a fairly straightforward data structure, isn't it? Not deeply recursive or a complicated graph. One experiment would be to create a list with, say, 100,000 random foo at example.com addresses and benchmark how much time it takes to unpickle it. I'll try to do that tomorrow on a real computer (not this laptop). --amk From Max.Lanfranconi at Sun.COM Wed Aug 6 03:01:56 2008 From: Max.Lanfranconi at Sun.COM (Massimo Lanfranconi) Date: Tue, 05 Aug 2008 18:01:56 -0700 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: References: Message-ID: <4898F804.40105@sun.com> Mark, I am more than willing to try any workaround as this bug is currently a showstopper for my project. I am not very versed in mailman internals, so I need some guidance here. Do you recommend I try getting rid of the __timestamp test and give it a try ? If that is you suggestion, may I ask what was the original purpose of that test ? Thanks again for your help in solving this. Regards, Max Mark Sapiro wrote: > Max Lanfranconi wrote: > > >> I tried the "sleep" approach as well. But then I thought that it was not >> viable. >> I am setting a relatively high number of mailing list that will receive >> asynchronous "subscribe" requests via web and/or shell API. >> >> It would be simply not possible to prevent bug this from happening as >> the chance of two "subscribe" being processsed almost simultaneously are >> not that small... >> >> I also vote for some kind of timing/lock issue. >> > > > Based on my running of the test script (see > , > with > > LIST_LOCK_DEBUGGING = True > > I think I see the problem. It is related to qrunner list caching and > the fact the there is insufficient precision in the list instance's > __timestamp > > The scenario is the following > > 1) add_member saves the list with the first member. > 2) VirginRunner gets there first, instantiates and caches the list. > It then locks the list, processes the welcome and saves and unlocks > the list. > 3) add_member gets the lock, adds the second member and saves the list. > 4) Virgin runner gets the second welcome. The list is cached, so it > uses the cached instance. It then locks the list which ultimately > calls MailList.__load() to refresh the list data, but __load() > does > > mtime = os.path.getmtime(dbfile) > if mtime <= self.__timestamp: > # File is not newer > return None, None > > The problem is os.path.getmtime() returns a time in seconds so if > we are still in the same second as step 2), we don't refresh the > list. > > Thank you very much Max for providing a script to reproduce the problem. > > I'm not sure of the best solution. I'm leaning towards dropping the > __timestamp test or perhaps replacing it with a file size test, but > that too may be unreliable. > > Other thoughts? > > -- -- * Max Lanfranconi * JCP Program Management Office Marketing Manager Phone +1 408 404 6893 Mobile +1 408 505 1020 Email max at jcp.org From mark at msapiro.net Wed Aug 6 06:03:15 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 05 Aug 2008 21:03:15 -0700 Subject: [Mailman-Developers] Subscribers suddenly "disappear" In-Reply-To: References: Message-ID: <48992283.6010706@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Sapiro wrote: | What I suggest for the moment is to just delete lines 594-603 of | Mailman/MailList.py which includes the following 4 lines and the | preceding comment. | |>> mtime = os.path.getmtime(dbfile) |>> if mtime <= self.__timestamp: |>> # File is not newer |>> return None, None Ooops!. That won't quite do it. you can't just remove the ~ mtime = os.path.getmtime(dbfile) line as mtime is referenced later and will be undefined. A patch is attached which has been applied and tested. I ran the test script twice with this patch installed with no lost subscribers. It isn't the final patch which should remove __timestamp completely and won't remove all the comment, but it will do as a workaround. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFImSKDVVuXXpU7hpMRArrKAJ9K2fA8MzI7Iarp0WfnNClwtwVbdACfaxCO Xsx7ru3fK2/v5ZRw0YHYU9s= =BdZw -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MailList.patch.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MailList.patch.txt.sig Type: application/octet-stream Size: 65 bytes Desc: not available URL: From stephen at xemacs.org Wed Aug 6 19:04:56 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 07 Aug 2008 02:04:56 +0900 Subject: [Mailman-Developers] Enabling topics with only one topic: can't exclude topic? In-Reply-To: <4899ACB0.8070901@arbash-meinel.com> References: <4898B0C3.4070308@aaronbentley.com> <1217966560.28917.51.camel@flash> <4898B48D.3030103@aaronbentley.com> <1217968688.28917.63.camel@flash> <4899ACB0.8070901@arbash-meinel.com> Message-ID: <87abfq2hxj.fsf@uwakimon.sk.tsukuba.ac.jp> Context: The bzr developers are considering splitting their Mailman list into a -dev and a -user list, but they don't like that because they feel it would split their community in an undesirable way. So the proposal is to create a [codereview] topic which gets workflow-related posts (nitty-gritty coding style comments as well as automatically generated messages from a patch queue manager). Most users aren't going to be interested in these, but will be interested in bug reports and their resolutions, and in design discussions, which will not get an explicit topic. So many users would like to select *only* messages *without* explicit topic. The quoted post claims that appears to be impossible. Seems like a bug to me, either in the topic feature (if it *is* impossible) or in the page template documenting usage. John Arbash Meinel writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Pool wrote: > | I've set up a Mailman topic "codereview", and people can use this to > | opt out of getting review related mail. (Or, if you want, to get only > | code reviews, but that would look a bit strange.) > | > | Messages will be classified into this topic if they have either > | [merge] or [codereview] in the Subject, or in a Keywords header, or in > | a pseudoheader in the top 5 lines of the message body. > | > | I have to say that the interface through which users can configure > | this is not so obvious and people who want it may not find it. But, > | it's there and we can see how it goes. > | > | If anyone wants to try it out: go to > | , enter your address, > | and scroll to the bottom of the resulting page. If it doesn't work as > | intended please let me know. > | > > So, I was reading through the description, and I found this: > > | If you do not select any topics of interest, you will get all the messages > | sent to the mailing list. > > And the description below that is: > | Do you want to receive messages that do not match any topic filter? > | > | This option only takes effect if you've subscribed to at least one > topic above. > > > So there is a problem. There is no way to say that don't want codereview > messages. > > You can get *only* codereview by checking the box, and then saying you > don't want unmatched messages. > > You can get all messages by either not checking codereview, or by > checking it and saying you *do* want unmatched messages. > > It seems that the only way to get what non-reviewers want, is to have > multiple topics, perhaps one as a dummy "ijustwanttodisablecodereview" > topic. > > Further, I *do* like the idea of sending merge requests directly to BB, > and having it forward the messages to the list. I think it could be an > optional feature for people who know the BB address. I suppose that I'm > a bit concerned with BB's stability if we do implement this. Because if > BB goes down, then all of our submissions get circular filed (trashed > until bounce, or whatever). > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiZrLAACgkQJdeBCYSNAAPEcgCeIpAOODfcymjQ4y9x3MAO4tyT > Y4gAoJe/WS0vmrSsZ8GGz40OyIVGegrf > =OjCX > -----END PGP SIGNATURE----- > From barry at list.org Wed Aug 6 19:27:47 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 6 Aug 2008 13:27:47 -0400 Subject: [Mailman-Developers] Enabling topics with only one topic: can't exclude topic? In-Reply-To: <87abfq2hxj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4898B0C3.4070308@aaronbentley.com> <1217966560.28917.51.camel@flash> <4898B48D.3030103@aaronbentley.com> <1217968688.28917.63.camel@flash> <4899ACB0.8070901@arbash-meinel.com> <87abfq2hxj.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 6, 2008, at 1:04 PM, Stephen J. Turnbull wrote: > The bzr developers are considering splitting their Mailman list into a > -dev and a -user list, but they don't like that because they feel it > would split their community in an undesirable way. So the proposal is > to create a [codereview] topic which gets workflow-related posts > (nitty-gritty coding style comments as well as automatically generated > messages from a patch queue manager). Most users aren't going to be > interested in these, but will be interested in bug reports and their > resolutions, and in design discussions, which will not get an explicit > topic. > > So many users would like to select *only* messages *without* explicit > topic. The quoted post claims that appears to be impossible. Seems > like a bug to me, either in the topic feature (if it *is* impossible) > or in the page template documenting usage. JAM pinged me in private irc and he's going to try to create a dummy topic which users can subscribe to to essentially filter out the codereview tags. It's a bit tricky because you have to create a negative regexp that's narrower than .* for the dummy topic. I think underneath the u/i it might not be difficult to support a "don't subscribe to this topic" setting. That's something for 2.2 though, as I think it's a new feature. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiZ3xQACgkQ2YZpQepbvXGuFgCeKnOK498lt+oOZDQx54orXrM+ 6XEAn0cyLCa8ROs8rcEnMZ0IJoKimejU =QQwV -----END PGP SIGNATURE----- From Max.Lanfranconi at Sun.COM Wed Aug 6 10:01:39 2008 From: Max.Lanfranconi at Sun.COM (Max Lanfranconi) Date: Wed, 06 Aug 2008 01:01:39 -0700 Subject: [Mailman-Developers] Subscribers suddenly "disappear" In-Reply-To: <48992283.6010706@msapiro.net> References: <48992283.6010706@msapiro.net> Message-ID: <48995A63.2090108@sun.com> Woohooo! Applied your patch and the bug is gone ! So far, so good. Thanks Mark ! Much, much appreciated. Max Mark Sapiro wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Sapiro wrote: > > | What I suggest for the moment is to just delete lines 594-603 of > | Mailman/MailList.py which includes the following 4 lines and the > | preceding comment. > | > |>> mtime = os.path.getmtime(dbfile) > |>> if mtime <= self.__timestamp: > |>> # File is not newer > |>> return None, None > > > Ooops!. That won't quite do it. you can't just remove the > > ~ mtime = os.path.getmtime(dbfile) > > line as mtime is referenced later and will be undefined. A patch is > attached which has been applied and tested. I ran the test script twice > with this patch installed with no lost subscribers. It isn't the final > patch which should remove __timestamp completely and won't remove all > the comment, but it will do as a workaround. > > - -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > > iD8DBQFImSKDVVuXXpU7hpMRArrKAJ9K2fA8MzI7Iarp0WfnNClwtwVbdACfaxCO > Xsx7ru3fK2/v5ZRw0YHYU9s= > =BdZw > -----END PGP SIGNATURE----- > ------------------------------------------------------------------------ > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/max.lanfranconi%40sun.com > > Security Policy: http://wiki.list.org/x/QIA9 From barry at list.org Fri Aug 8 22:58:07 2008 From: barry at list.org (Barry Warsaw) Date: Fri, 8 Aug 2008 16:58:07 -0400 Subject: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear" In-Reply-To: <20080806015019.GA14859@amk.local> References: <20080806015019.GA14859@amk.local> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2008, at 9:50 PM, A.M. Kuchling wrote: > On Tue, Aug 05, 2008 at 09:13:07PM -0400, Barry Warsaw wrote: >> I wonder if the list cache is still worth it? I've run into trouble >> with it in the recent past and I suspect that whatever benefits we >> got >> from it in ancient times, may not be so relevant today. My first > > I expect cPickle or even pickle are pretty fast, and the config.pck is > a fairly straightforward data structure, isn't it? Not deeply > recursive or a complicated graph. One experiment would be to create a > list with, say, 100,000 random foo at example.com addresses and benchmark > how much time it takes to unpickle it. I'll try to do that tomorrow > on a real computer (not this laptop). Hi Andrew, any results? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkics18ACgkQ2YZpQepbvXFX2gCdHOghfr9eb6xRZ1/delxPnw+2 t3wAnjgqAQhtiUUGYQSqQF0VT+ATyt+V =tyGZ -----END PGP SIGNATURE----- From amk at amk.ca Fri Aug 8 23:41:40 2008 From: amk at amk.ca (A.M. Kuchling) Date: Fri, 8 Aug 2008 17:41:40 -0400 Subject: [Mailman-Developers] Subscribers suddenly"disappear" In-Reply-To: References: <20080806015019.GA14859@amk.local> Message-ID: <20080808214140.GA8546@amk-desktop.matrixgroup.net> On Fri, Aug 08, 2008 at 04:58:07PM -0400, Barry Warsaw wrote: >> recursive or a complicated graph. One experiment would be to create a >> list with, say, 100,000 random foo at example.com addresses and benchmark >> how much time it takes to unpickle it. I'll try to do that tomorrow >> on a real computer (not this laptop). > > Hi Andrew, any results? The simple test program I used is below. For a list with 89531 addresses, the config.pck file is 9248317 bytes = 8.9M. Doing ten loads and then ten saves in a row, the average load time is 1.36sec and the average save time is 4.5sec. This is on a development server here at Matrix, which has two 1.1GHz Intel CPUs and 2Gb of RAM; a respectable machine, but not what you'd currently use for a server. So I think pickle really is pretty fast. Of course, if you had your Mailman installation on a busy mail or database server, all that I/O might kill you, but I think giving up on the mtime caching is not completely unreasonable. --amk import time from Mailman import MailList L = [] for i in range(10): s = time.time() ml = MailList.MailList('amk-speed-test', lock=1) e = time.time() ml.Unlock() L.append(e-s) print e-s print 'Average loading time=', sum(L)/len(L) L = [] ml.Lock() for i in range(10): s = time.time() ml.Save() e = time.time() L.append(e-s) print e-s ml.Unlock() #print L print 'Average save time=', sum(L)/len(L) From barry at python.org Fri Aug 8 23:45:46 2008 From: barry at python.org (Barry Warsaw) Date: Fri, 8 Aug 2008 17:45:46 -0400 Subject: [Mailman-Developers] Subscribers suddenly"disappear" In-Reply-To: <20080808214140.GA8546@amk-desktop.matrixgroup.net> References: <20080806015019.GA14859@amk.local> <20080808214140.GA8546@amk-desktop.matrixgroup.net> Message-ID: <1A541140-EA03-4CE7-B63F-59DE81E3940C@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 8, 2008, at 5:41 PM, A.M. Kuchling wrote: > On Fri, Aug 08, 2008 at 04:58:07PM -0400, Barry Warsaw wrote: >>> recursive or a complicated graph. One experiment would be to >>> create a >>> list with, say, 100,000 random foo at example.com addresses and >>> benchmark >>> how much time it takes to unpickle it. I'll try to do that tomorrow >>> on a real computer (not this laptop). >> >> Hi Andrew, any results? > > The simple test program I used is below. For a list with 89531 > addresses, the config.pck file is 9248317 bytes = 8.9M. Doing ten > loads and then ten saves in a row, the average load time is 1.36sec > and the average save time is 4.5sec. > > This is on a development server here at Matrix, which has two 1.1GHz > Intel CPUs and 2Gb of RAM; a respectable machine, but not what you'd > currently use for a server. So I think pickle really is pretty fast. > Of course, if you had your Mailman installation on a busy mail or > database server, all that I/O might kill you, but I think giving up on > the mtime caching is not completely unreasonable. Thanks for the feedback Andrew. I don't know if it's worth changing for 2.1; I think it's a rare problem and the workarounds are now all in the archive. It's probably worth changing for 2.2 (and is of course moot for 3.0), but it's still probably not worth making it configurable. For 2.2, let's do the right thing and if we can make it fast in the meantime, great! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSJy+inEjvBPtnXfVAQJiYgP+LPZABA78c604XzB39lBpkF/mfu/EEPE8 7aojEnqdaiorAA4PLQppAPNuF8oz9rQU87q/WVSJLdUo87HieTqddOy/CFwPJfYS ixdJmc/k2TdnoLSFykcHhriJUQtfB1TNCodPG2BbFer7b4tEjyIRK11W6bC4gIM5 HfHYl1GLuck= =ARJn -----END PGP SIGNATURE----- From sourcedaniel at gmail.com Tue Aug 12 22:17:05 2008 From: sourcedaniel at gmail.com (Daniel Harris) Date: Tue, 12 Aug 2008 13:17:05 -0700 Subject: [Mailman-Developers] Web Interface to Mailman using Zope Message-ID: Hi, I have put together a proof-of-concept UI to Mailman using Zope. It currently implements two functions: viewing a list of lists and creating a new list. I am announcing this to the developers' list: o to see if there is interest in using Zope / Plone as the basis for a user interface o to enquire about how I might best continue this work. I created the prototype to start exploring whether Plone and Mailman could be integrated to support a community organisation I'm working with. In particular, I wanted participants to be able to: o manage their mailing list subscriptions through Plone o view mailing list messages through Plone, email or RSS o send messages to mailing lists by email or Plone. The implementation comprises a Zope product, a bridge, and a server that provides access to Mailman functions. I'm currently using Corba for the bridge as I'm not familiar with REST - but I am planning to transfer to the REST interface as its implementation develops. The interface (around five entries) provides access to Mailman functions to list mailing lists, create a mailing list and list available languages. Additional functions are defined to check the arguments used to create a new list - these functions are used by the ZPT page to display errors needing correction to the end user. Your advice and comments are requested. I have read through previous discussions and documents about the web interface in the mailing lists and on the developers' wiki. Regards, Daniel. From barry at list.org Sat Aug 16 00:01:47 2008 From: barry at list.org (Barry Warsaw) Date: Fri, 15 Aug 2008 18:01:47 -0400 Subject: [Mailman-Developers] Demo import of bugs/patches/rfes to Launchpad Message-ID: <3E4C749D-20C0-4C26-B4E2-64275A22921D@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce a demo import from SourceForge's bug tracker, patches tracker, and feature request tracker into Launchpad, and I invite you to play with the new issue tracker so that we can decide whether or not to complete this step of project hosting migration. The url is Things to note: This is a /demo/ import meaning that you can play with it all you want and it will not affect the eventual production import of the issues. This is a live demo though, so you should be able to try out all the features you would have access to in the main Launchpad site. Just remember that at the end of the demo, all these changes will be lost. All three SF trackers have been collapsed into one tracker on LP. With only 632 open issues, hopefully this will not be a problem, but if it is we can at least just import the bug tracker when/if we switch. If we wanted to import all three trackers but keep them separate, we'd have to figure something out. I don't have a timeframe for converting, or deciding to convert. Much depends on your feedback (and especially Mark's) and the readiness of the LP administrators to do the production import. I think if we like it, we could make the switch fairly quickly. Please send your feedback to me and I will communicate it back to the Launchpad developers working on this. My thanks go to Graham Binns and Tom Haddon. Enjoy, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkil/MwACgkQ2YZpQepbvXE0YgCdEdgPHKbXjd/JIlxenrlQmdUi fEoAn2QuaTwi/H1Ks9AYVEnFeFQLi7lZ =OHCC -----END PGP SIGNATURE----- From mark at msapiro.net Wed Aug 20 03:25:55 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 19 Aug 2008 18:25:55 -0700 Subject: [Mailman-Developers] Demo import of bugs/patches/rfes to Launchpad In-Reply-To: <3E4C749D-20C0-4C26-B4E2-64275A22921D@list.org> References: <3E4C749D-20C0-4C26-B4E2-64275A22921D@list.org> Message-ID: <48AB72A3.8060201@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: > I'm happy to announce a demo import from SourceForge's bug tracker, > patches tracker, and feature request tracker into Launchpad, and I > invite you to play with the new issue tracker so that we can decide > whether or not to complete this step of project hosting migration. > > The url is > > I don't have a timeframe for converting, or deciding to convert. Much > depends on your feedback (and especially Mark's) and the readiness of > the LP administrators to do the production import. I think if we like > it, we could make the switch fairly quickly. I've played with it a little bit, and I think it will be fine. One of the obvious advantages is the tighter integration with bazaar (I guess any would be tighter than what we have :) I think it's fine to convert. I wonder if it is possible in the conversion to map SF users to LP users where there is a correspondence, e.g. instead of mapping SF msapiro to LP Msapiro-users, map to LP Mark Sapiro. Or if there is a way after the fact to say Msapiro-users is me. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIq3KjVVuXXpU7hpMRAnq5AKCkaNrP8e23TjfFjhAyjAK+4PPTIACg1W7I LG6GwR2D9MC6fajycbq8KKc= =fvIu -----END PGP SIGNATURE----- From mark at msapiro.net Fri Aug 22 02:27:19 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 21 Aug 2008 17:27:19 -0700 Subject: [Mailman-Developers] Subscribers suddenly"disappear" In-Reply-To: <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <48AE07E7.2090900@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen J. Turnbull wrote: > > Mark Sapiro writes: > > > 1) add_member saves the list with the first member. > > 2) VirginRunner gets there first, instantiates and caches the list. > > It then locks the list, processes the welcome and saves and unlocks > > the list. > > 3) add_member gets the lock, adds the second member and saves the list. > > 4) Virgin runner gets the second welcome. The list is cached, so it > > uses the cached instance. It then locks the list which ultimately > > calls MailList.__load() to refresh the list data, but __load() > > does > > > > mtime = os.path.getmtime(dbfile) > > if mtime <= self.__timestamp: > > # File is not newer > > return None, None > > Shouldn't "mtime < self.__timestamp" do the right thing (much more > often)? I didn't reply sooner because when I first saw this, I didn't read it carefully, and I didn't "get" what Stephen was saying. Then I had to think about it. I have concluded that barring resetting of clocks backward, "mtime < self.__timestamp" is equivalent to "False". Whenever a config.pck is written or read in a process, __timestamp is set to the current mod time of the config.pck. Thus, the value of self.__timestamp for a cached list object is always <= mtime. > You're still vulnerable to "date -s", adjtime, and friends, > though, and of course you'll have some undesirable cache misses at > times when it would be nice if you didn't. Always, I think. > A better way would be to add a serial number. As has already been mentioned, it does no good to put a serial number in the list object since you'd have to read the config.pck to get the serial number. It would have to be encoded in the file name or stored in a separate database. Storing it separately adds the complication of an additional file plus making sure the additional file is sync'd with config.pck. Encoding it in the file name seems complex as well. I lean towards the simpler approach of just reading the config.pck every time. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIrgfnVVuXXpU7hpMRApeVAKDAv5aw4Mc8x6P9KevoWIBYIjaqFgCcDlcq FpC83W+m1C8Vjlfql27QrtA= =/joM -----END PGP SIGNATURE----- From mark at msapiro.net Fri Aug 22 22:34:47 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 22 Aug 2008 13:34:47 -0700 Subject: [Mailman-Developers] Subscribers suddenly"disappear" In-Reply-To: <48AE07E7.2090900@msapiro.net> References: <48AE07E7.2090900@msapiro.net> Message-ID: <48AF22E7.9040507@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Sapiro wrote: > Stephen J. Turnbull wrote: >> >> Mark Sapiro writes: >> >> > 1) add_member saves the list with the first member. >> > 2) VirginRunner gets there first, instantiates and caches the list. >> > It then locks the list, processes the welcome and saves and unlocks >> > the list. >> > 3) add_member gets the lock, adds the second member and saves the list. >> > 4) Virgin runner gets the second welcome. The list is cached, so it >> > uses the cached instance. It then locks the list which ultimately >> > calls MailList.__load() to refresh the list data, but __load() >> > does >> > >> > mtime = os.path.getmtime(dbfile) >> > if mtime <= self.__timestamp: >> > # File is not newer >> > return None, None >> >> Shouldn't "mtime < self.__timestamp" do the right thing (much more >> often)? > > > I didn't reply sooner because when I first saw this, I didn't read it > carefully, and I didn't "get" what Stephen was saying. Then I had to > think about it. > > I have concluded that barring resetting of clocks backward, "mtime < > self.__timestamp" is equivalent to "False". Whenever a config.pck is > written or read in a process, __timestamp is set to the current mod time > of the config.pck. Thus, the value of self.__timestamp for a cached list > object is always <= mtime. I have thought about this some more and have come up with the attached patch which I have tested with Max's script and propose for Mailman 2.2. The patch changes the '<=' test to '<' as Stephen suggests, but then so it won't effectively disable ever not reloading the config.pck, it changes the setting of __timestamp following a successful read from the mod time of the config.pck to the current time truncated to an int. Thus, once we've read a config.pck that's more than a second old, a subsequent load of the same object will skip rereading the config.pck if it wasn't updated in the interim. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIryLmVVuXXpU7hpMRApoCAJ9hPl/yxi8n9ZAT04s2+TCG6/rvbwCg1NJ6 HlgyY/PB3s6l7B4diGO0zb8= =5V+H -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MailList.patch.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MailList.patch.txt.sig Type: application/octet-stream Size: 65 bytes Desc: not available URL: From mark at msapiro.net Sun Aug 24 04:49:49 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 23 Aug 2008 19:49:49 -0700 Subject: [Mailman-Developers] Enabling topics with only one topic: can'texclude topic? In-Reply-To: Message-ID: Barry Warsaw wrote: > >On Aug 6, 2008, at 1:04 PM, Stephen J. Turnbull wrote: > >> The bzr developers are considering splitting their Mailman list into a >> -dev and a -user list, but they don't like that because they feel it >> would split their community in an undesirable way. So the proposal is >> to create a [codereview] topic which gets workflow-related posts >> (nitty-gritty coding style comments as well as automatically generated >> messages from a patch queue manager). Most users aren't going to be >> interested in these, but will be interested in bug reports and their >> resolutions, and in design discussions, which will not get an explicit >> topic. >> >> So many users would like to select *only* messages *without* explicit >> topic. The quoted post claims that appears to be impossible. Seems >> like a bug to me, either in the topic feature (if it *is* impossible) >> or in the page template documenting usage. > >JAM pinged me in private irc and he's going to try to create a dummy >topic which users can subscribe to to essentially filter out the >codereview tags. It's a bit tricky because you have to create a >negative regexp that's narrower than .* for the dummy topic. > >I think underneath the u/i it might not be difficult to support a >"don't subscribe to this topic" setting. That's something for 2.2 >though, as I think it's a new feature. I'm thinking of handling it differently. Namely, just changing "Do you want to receive messages that do not match any topic filter?" so that it works even if you are not subscribed to any topic and sends you everything that doesn't match, but not anything that does match. It seems that that would handle the "everything but the one defined topic" case as well as the more general "I don't want any of the defined topics, but I want everything else" case. Thoughts? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sun Aug 24 06:02:31 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 23 Aug 2008 21:02:31 -0700 Subject: [Mailman-Developers] Enabling topics with only one topic:can'texclude topic? In-Reply-To: Message-ID: Mark Sapiro wrote: > >I'm thinking of handling it differently. Namely, just changing "Do you >want to receive messages that do not match any topic filter?" so that >it works even if you are not subscribed to any topic and sends you >everything that doesn't match, but not anything that does match. It >seems that that would handle the "everything but the one defined >topic" case as well as the more general "I don't want any of the >defined topics, but I want everything else" case. Note there would either have to be a special case where no subscribed topics and "Do you want to receive messages that do not match any topic filter? = No" means receive all messages, or change it to a 3-way option - "only subscribed topics", "subscribed topics + no topic" or "all messages" - and migrate the setting appropriately. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Tue Aug 26 10:25:06 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 26 Aug 2008 04:25:06 -0400 Subject: [Mailman-Developers] Enabling topics with only one topic:can'texclude topic? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 24, 2008, at 12:02 AM, Mark Sapiro wrote: > Mark Sapiro wrote: >> >> I'm thinking of handling it differently. Namely, just changing "Do >> you >> want to receive messages that do not match any topic filter?" so that >> it works even if you are not subscribed to any topic and sends you >> everything that doesn't match, but not anything that does match. It >> seems that that would handle the "everything but the one defined >> topic" case as well as the more general "I don't want any of the >> defined topics, but I want everything else" case. > > Note there would either have to be a special case where no subscribed > topics and "Do you want to receive messages that do not match any > topic filter? = No" means receive all messages, or change it to a > 3-way option - "only subscribed topics", "subscribed topics + no > topic" or "all messages" - and migrate the setting appropriately. This one makes the most sense to me. I think it will be easiest to explain to users as well. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkizveIACgkQ2YZpQepbvXHJFgCdEy6wuZGsigNVB0dql/WHTXs/ SHwAoJfyevG359zsrEdOsOhH6rjnBScw =YKaX -----END PGP SIGNATURE----- From barry at list.org Tue Aug 26 10:49:50 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 26 Aug 2008 04:49:50 -0400 Subject: [Mailman-Developers] Subscribers suddenly"disappear" In-Reply-To: <48AE07E7.2090900@msapiro.net> References: <87fxpjvtke.fsf@uwakimon.sk.tsukuba.ac.jp> <48AE07E7.2090900@msapiro.net> Message-ID: <25B7C8FD-4475-4189-98D3-34E6597FAF4C@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 21, 2008, at 8:27 PM, Mark Sapiro wrote: > As has already been mentioned, it does no good to put a serial > number in > the list object since you'd have to read the config.pck to get the > serial number. It would have to be encoded in the file name or > stored in > a separate database. Storing it separately adds the complication of an > additional file plus making sure the additional file is sync'd with > config.pck. Encoding it in the file name seems complex as well. > > I lean towards the simpler approach of just reading the config.pck > every > time. +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkizw64ACgkQ2YZpQepbvXFMuwCfRKzhFhEnTIaQLl1YgqeuTp7w O3QAn3fRWR8OytLtI3F4JXjLnmhmgLsY =XpWr -----END PGP SIGNATURE----- From barry at list.org Tue Aug 26 11:21:46 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 26 Aug 2008 05:21:46 -0400 Subject: [Mailman-Developers] Demo import of bugs/patches/rfes to Launchpad In-Reply-To: <48AB72A3.8060201@msapiro.net> References: <3E4C749D-20C0-4C26-B4E2-64275A22921D@list.org> <48AB72A3.8060201@msapiro.net> Message-ID: <712EED12-8D37-413E-A80B-93F77ADD3718@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 19, 2008, at 9:25 PM, Mark Sapiro wrote: > I've played with it a little bit, and I think it will be fine. One of > the obvious advantages is the tighter integration with bazaar (I guess > any would be tighter than what we have :) :) > I think it's fine to convert. I wonder if it is possible in the > conversion to map SF users to LP users where there is a > correspondence, > e.g. instead of mapping SF msapiro to LP Msapiro-users, map to LP Mark > Sapiro. Or if there is a way after the fact to say Msapiro-users is > me. I'll double check, but I believe the way this is handled is that new users are created for each of the SF user names, and we (or the individual user) can request that those users be merged into your official LP user id. If there are no objections, I'll chat with the folks doing the import and let them know that we're ready to switch over. We'll schedule a flag day and make the announcement before actually switching over. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkizyyoACgkQ2YZpQepbvXEnzACfVUh8LIPtbEwAu4VEWp1mmUwC IqwAn2ORhWyAuNBdVJUBl+ZWaeAyJ9HY =tGzi -----END PGP SIGNATURE-----