I finally managed to find some vestige of free time after midnight
(hardly the best time to be coding...) recently, and accordingly put out
a new version of my MySQL MemberAdaptor.
I have no time, and little motivation (no customers wanting to use it at
the present time) to test it, so I haven't, but you're welcome to try it
It should according to the docs I found, provided I've applied them
correctly, fix the non-ASCII character encoding problems (I've relied on
the assertions about list members to cover that angle, and just checked
encoding on the 'user supplied' parameters to various function calls).
Now would be a good time for someone to send me a Python language
reference book ;-)
However since I've changed development environment since the last
version, it's possible that various things have gone wrong (certainly
the version numbering has gone mad between RCS and CVS/Eclipse), so
don't do it in a production environment.
I've put it here, as version 1.71, whatever that might actually mean:
Incidentally, since Fil seems to be taking all the credit for what I
started I think he should actually put a proper credit in there for me,
linking to my business website at http://www.orenet.co.uk/ rather than
the vague passing mentions that are in the docs/code of his version of
the system at the present time.
With luck I will be able to coax one of my customers into 'sponsoring'
further development of the MySQL Adaptor with proper integration into
Mailman in a sane way that is agreed by everyone instead of (as seems
to be the case from what little of this list I have had time to read)
just going off on its own sweet way and reducing the likelyhood of
acceptance into the main code base of Mailman, but I am not sure how
that will go. If anyone else wants to sponsor my time to code this thing
better and further, then just email me.
Best of luck with it, whatever happens. More updates in whichever year I
manage to find spare/free time.
I have a client who is looking to move to an In-House mailing
system. They are currently using a commercial web company called
vertical response, http://www.verticalresponse.com. They would like
some assistance in developing some back end tools and interface to do
tacking on their mailings.
If someone out there is interested in working with us on this
project, please let me know. You can call my office or send me back
an email. The client is ready to move forward and any help would be
appreciated. I would prefer to go with Mailman on this project. I
think it can handle what they want to do, but I just need help on the
backend and interface.
Thanks in advance.
Thomas M Foley
TMF Consulting LLC
I'm currently looking at creating a fork of mailman to add
support for GPG encrypted mailing lists, however given that mailman is
a rather complex beast I'm having trouble figuring out where to start.
Can somebody direct me to a good structural overview of how all the
bits and pieces of mailman fit together?
Thanks in advance,
Okay, I've actually picked through the code (both the MySQL adaptor and
Fil's code) on this one and made a couple of observations, and I think
I've definitively found the culprit here.
We're looking at Mailman/Cgi/admin.py here. Lines 871 onwards, for
between 5 and 20 lines depending on whether you're looking at Fil's
modified code or the distributed version.
This is the case (although different code surrounds the offending bits)
up to and including the latest 2.1.11 version, and of course only if I
read the Python right ;-)
First pass of the code suggested that Fil's code was a bit wide of the
mark, although it would work for searches.
This is because the patched code only uses his getMembersMatching()
method if we are not given an empty search string (and the code uses the
same search method of getMembers() with an empty string as a defined
search string), so listing all members in order with Fil's code will be
missing the "names" array, and be fast, but my original will populate
the "names" array, and be cripplingly slow for large lists.
This, however is not the source of the problem.
Fil's code seems to only call his getMembersMatching() method to
populate the 'all' array, and disregards the users "names" array, which
is populated in the normal version. I don't suppose he's bothered about
people's 'real name' values ;-)
This is the root cause of the problem, because it's doing a foreach-type
loop through all the members retrieved by getMembers() to get their
names individually, rather than making a single database call to get
them all, which would seem to be the cause of the slowness. It is even
noted by Barry that this bit of code sucks:
# BAW: There's got to be a more efficient way of doing this!
names = [mlist.getMemberName(s) or '' for s in all]
Therefore I would propose a change to admin.py that calls a member
adaptor's mlist.getAllMemberNames() if it exists/is implemented,
otherwise defaults to doing the aforementioned instead, which is ok for
pickles. The obvious caveat is that getAllMemberNames() MUST return
members in the same order as the getMembers() function or it'll cause
funny things to happen.
As long as we know what to sling into the SQL 'ORDER BY' that'll be fine
though. I'd assume ordering by lower case address is the way it happens
I suppose you could just move that offending line of code into a
getAllMemberNames() function in OldStyleMemberships.py too though?
This would allow SQL to do its thing in two shots (once for names, and
once for addresses) rather than loads of individual user queries (once
for addresses, loads of times for names), and remove the bottleneck,
while also minimising the required mangling of core code.
It would also allow backward compatibility, just *very slow* backward
compatibility by not calling the new method in the adaptor ;-)
Kev Green, aka Kyrian. E: email@example.com WWW: http://kyrian.ore.org/
Linux/Security Contractor/LAMP Coder/ISP, via http://www.orenet.co.uk/
DJ via http://www.hellnoise.co.uk/
As requested in http://www.gnu.org/software/mailman/devs.html, I would
like to note that I noticed a bug in gate_news (mailman-2.1.11), for which a
fix has been proposed a couple of years ago. I applied this fix, and it
solved the problem for me, so I suggest that this fix goes into the next
mailman release if the developers don't see potential problems with it.
More details are here:
Markus Grabner - Computer Graphics and Vision
Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria
Phone: +43/316/873-5041, Fax: +43/316/873-5050
-----BEGIN PGP SIGNED MESSAGE-----
We're planning on migrating the current SourceForge trackers for the
Mailman project to Launchpad, this Thursday at 1200 UTC. Expect the
conversion to take several hours.
The SF trackers will still be available during the conversion, though
I will try to remove as much write access to them as possible. Please
be aware that any changes that occur to SF issues during the
conversion will be lost.
I'll send another announcement when the conversion is complete.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
-----END PGP SIGNATURE-----
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
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
> 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"
> 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).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----