Title: Mailman Developer Resources Links: Other-links:

Developer Exits

Developer Resources

If you're the kind of person who loves to get elbow deep in code, there are lots of opportunities to dig into Mailman. You may want to find a project on our Mailman TODO list or on the Mailman design notes wiki. Because Wikis are intended to be collaborative, you're free to contribute to this page in true Wiki fashion. You will also definitely want to subscribe to the mailman-developers mailing list.

SourceForge Project Page

Developers should start with the Mailman project at SourceForge. All patches and bugs should be submitted here so they won't get lost, although it is also requested that you inform the mailman-developers list about your submissions.

IRC

Some of the Mailman developers also occasionally hang out on the mailman IRC channel at openprojects.net, though attendance has been spotty lately.

Future plans

Now that Mailman 2.1 has been released, I want to start thinking about what will be in Mailman 3.0. I intend to use the wiki for most design artifacts, and the mailman-developers mailing list for most discussions. The items that are high on my list (which is by no means complete or definitive) include:

Consolidated user database -- A user should have just one account for every mailing list they are members of at a site, and they should be able to manage all their options through this account. It should be possible to integrate these databases with a site's existing user management system to reduce duplication of data and effort.
Unified template system -- Mailman has a somewhat fractured and inconvenient templating system, using both a homegrown HTML object model in Python and coarse templates filled in with data at rendering time. It can be near impossible to change the look and feel of the administration pages, and a small change to the u/i of other pages requires updates in all supported languages. I want to use a templating system like ZPT or Quixote. Actually, I plan to generalize the web interface so that many different templating systems could be used, although we'll pick one to ship by default.
A Real Database -- Mailman uses an inefficient persistency system based on Python pickles, and every mailing list has its own pickled state. This has several disadvantages, including poor scalability, difficulty in doing cross-mailing list operations, and the virtual host limitation on list names. Mailman 3.0 will use a real database, perhaps based on ZODB or BerkeleyDB. Again, the goal is to generalize the interface to the backend database so that others can be used, but choose one and ship it by default.
Component Architecture -- Zope3's component architecture provides some very nice organizational tools and software development methodologies. We'll be adopting many of these for Mailman 3.0, which will allow us to do the kinds of templating and database generalization described above.

Stephan Richter has let an effort called ZMailman for integrating Zope and Mailman. I consider this a proof of concept of some of the ideas outlined above.