Testing Mailman 2.2

Mailman 2.2 is currently under development. It is not yet ready for prime time, but as always it is very helpful if people grab the latest Subversion trunk and test it as much as possible. Please do not use the SourceForge bug tracker if you find problems in Mailman; instead the best thing to do is email mailman-developers@python.org.

Getting the source code

Currently, the only way to get the Mailman 2.2 source code is to check out the Subversion trunk, the repository of which is on SourceForge. If you don't know how to use Subversion, or have questions about how to specifically check out the code from SourceForge, please read the SourceForge Subversion documentation.

All of the Mailman 2.2 code is currently on the Subversion trunk, so to check it out use the following command (for read-only access):

svn co https://mailman.svn.sourceforge.net/svnroot/mailman/trunk/mailman mailman

Building the code

Mailman 2.2 builds just like Mailman 2.1. In other words, you first run configure, then make and finally make install. By default, Mailman 2.2 installs in the same location as Mailman 2.1 so there are two things to remember:

• Do not install Mailman 2.2 on a production machine because you will break stuff!

• Use the --prefix option to {{configure} to install Mailman 2.2 in its own location

I find it very handy to have both Mailman 2.1 and 2.2 installed on my dev box so that I can compare things, or experiment with upgrading, etc. On my dev machine I use --prefix /usr/local/mailman21 to install Mailman 2.1 and --prefix /usr/local/mailman22 to install Mailman 2.2. YMMV.

Running the code

In Mailman 2.1, you customized things by editing the Mailman/mm_cfg.py file, relative to your installation prefix. In Mailman 2.2, you instead edit etc/mailman.cfg. The format of the file is similar – it contains Python code – so you might be able to start by just copying the contents of your Mailman 2.1 mm_cfg.py file to mailman.cfg. Don't copy mm_cfg.py directly though; for the time being it's still loaded after mailman.cfg although that may change. There are some differences, especially in how you set up your virtual domains and how you integrate with your MTA, so read through Defaults.py again if it's been a while. Also, take a look at etc/mailman.cfg.sample. I will try to upload my configuration file too.

One thing in particular you will want to do is to extend the QRUNNERS variable. Mailman 2.2 now supports local delivery via LMTP which most of the common mail servers support in one way or another. I'm not yet certain whether LMTP delivery will be the only way for Mailman 2.2 or whether we'll continue to support the legacy program delivery machinery.

Another big change for Mailman 2.2 is that it includes its own WSGI compliant, standalone web server. Currently Mailman 2.2 still integrates with an existing web server using CGI, but again, I'm unsure whether we'll keep this or just use WSGI.

For now the best way to start Mailman 2.2 is to add (at least) this to your mailman.cfg file:

QRUNNERS.extend([
    ('LMTPRunner', 1),
    ('HTTPRunner', 1),
])

and then use mailmanctl start as you would with Mailman 2.1. Run tail over the logs/qrunner file and make sure that both the LMTPRunner and HTTPRunner are started. Once the latter gets going, you should be able to hit your local interface, though notice that the /mailman/ prefix on URLs is gone. E.g.:

http://localhost.local:2580/admin

You might need to include an add_domain() call in your mailman.cfg file, and you may need to change the URL above to suit your settings.

At this point, you should be able to create new mailing lists, add members, change settings, etc. just like you could in Mailman 2.1. From the web u/i and the mail interface, you probably won't see much different at this point.

Importing Mailman 2.1 lists

There is some facility for importing your Mailman 2.1 lists into Mailman 2.2. Again, let me stress that Mailman 2.2 is not ready for production use. Importing will be the way you upgrade, but you don't want to be running real lists on Mailman 2.2 yet. It's very possible – no, very likely that you will have to blow away your Mailman 2.2 database from time to time, so you don't want any real data in there yet. There won't be a guaranteed upgrade path until we stabilize for beta release.

Still, I encourage you to experiment with import/export. The way this is done is by running the export.py script in Mailman 2.1 to produce an XML document, then running bin/import in Mailman 2.2 to recreate the lists in your new installation. At this point, all Mailman 2.1 data is imported properly. The export.py script will be part of Mailman 2.1.10, but you can get it now by checking out the Mailman 2.1 branch
and installing that as you normally would a Mailman 2.1 installation. My recommendation again is not to use a production server for this. Instead, install Mailman 2.1 on your dev machine, then copy over your /usr/local/mailman/lists subdirectory, and then running export.py on the dev box.

What else?

That's all I can think of at the moment. If you have questions, please use the developers list or post them as comments here and I will flesh the documentation out in response.

Comments

USE_LMTP = Yes
add_qrunner('HTTP')

alias_maps = hash:/etc/aliases
    hash:/usr/local/mailman/data/aliases
alias_database = hash:/etc/aliases
virtual_alias_maps = hash:/etc/postfix/virtual
    hash:/usr/local/mailman/data/virtual-mailman
transport_maps = hash:/usr/local/mailman/data/transport
    hash:/etc/postfix/transport
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
    $virtual_alias_maps $transport_maps