Mailman-Developers August 2008

mailman-developers@python.org

7 participants
5 discussions

Enabling topics with only one topic: can't exclude topic?

by Stephen J. Turnbull

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 > | <https://lists.ubuntu.com/mailman/options/bazaar>, 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----- >

12 years, 10 months

Demo import of bugs/patches/rfes to Launchpad

by Barry Warsaw

-----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 <https://bugs.demo.launchpad.net/mailman/+bugs> 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-----

12 years, 11 months

Re: [Mailman-Developers] [Mailman-Users] Subscribers suddenly "disappear"

by Max Lanfranconi

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 <Max.Lanfranconi(a)Sun.COM> 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(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist2 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist3 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist4 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist5 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist6 >> list-admin(a)domain.com testpwd >> >> >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> >> After a short wait the following output is received: >> >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> >> foo(a)bar.com receives 6 confirmation emails, as boo(a)foo.com does. S >> o far so >> good. >> >> At this point testlist1-6 each should contain 2 subscribers: foo(a)bar.com >> and boo(a)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(a)foo.com >> foo(a)bar.com >> foo(a)bar.com >> boo(a)foo.com >> foo(a)bar.com >> foo(a)bar.com >> foo(a)bar.com >> boo(a)foo.com >> foo(a)bar.com >> >> in which three instances of boo(a)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(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo(a)foo.com > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > boo(a)foo.com > foo(a)bar.com > 4 > boo(a)foo.com > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)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(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo(a)foo.com > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > foo(a)bar.com > 4 > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)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(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > foo(a)bar.com > 4 > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)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(a)anl.gov > Argonne, IL 60439-4828 IBMMAIL: I1004994 > > ------------------------------------------------------ > Mailman-Users mailing list > Mailman-Users(a)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.… > > Security Policy: http://wiki.list.org/x/QIA9 >

12 years, 11 months

Web Interface to Mailman using Zope

by Daniel Harris

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.

12 years, 11 months

Scheduled downtime for wiki.list.org

by Barry Warsaw

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

12 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers August 2008