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