~ubuntu-branches/ubuntu/hoary/mailman/hoary-security

Title: Mailman Developer Resources

Links:

Other-links:

    <h3>Developer Exits</h3>

    <li><a href="http://sourceforge.net/projects/mailman">SourceForge Project Page</a>

    <li><a href="http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/">Mailman Wiki</a>

    <li><a href="http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanThreePointOh">Mailman 3.0 Wiki</a>

    <li><a href="http://mail.python.org/mailman/listinfo/mailman-developers">mailman-developers list</a>

    <li><a href="http://demo.iuveno-net.de/iuveno/Products/ZMailman/">ZMailman</a>

    

<h3>Developer Resources</h3>

 

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

<a href="todo.html">TODO list</a> or on the

<a href="http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/">Mailman

design notes wiki</a>.  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 <a href="http://mail.python.org/mailman/listinfo/mailman-developers"

>mailman-developers</a> mailing list.

 

<h3>SourceForge Project Page</h3>

 

Developers should start with the

<a href="http://sourceforge.net/projects/mailman">Mailman project at

SourceForge</a>.  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.

 

<h3>IRC</h3>

 

Some of the Mailman developers also occasionally hang out on the

<em>mailman</em> IRC channel at openprojects.net, though attendance

has been spotty lately.

 

<!--table-stop-->

 

<h3>Future plans</h3>

 

Now that Mailman 2.1 has been released, I want to start thinking about

what will be in <a

href="http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanThreePointOh">Mailman

3.0</a>.  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:

 

<ul>

<li><b>Consolidated user database</b> -- 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.

 

<p><li><b>Unified template system</b> -- 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

<a href="http://dev.zope.org/Wikis/DevSite/Projects/ZPT/">ZPT</a> or

<a href="http://www.mems-exchange.org/software/quixote/">Quixote</a>.

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.

 

<p><li><b>A Real Database</b> -- 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

<a href="http://www.zope.org/Wikis/ZODB/">ZODB</a> or

<a href="http://www.sleepycat.com">BerkeleyDB</a>.  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.

 

<p><li><b>Component Architecture</b> -- Zope3's

<a href="http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/"

>component architecture</a> 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.

</ul>

 

Stephan Richter has let an effort called

<a href="http://demo.iuveno-net.de/iuveno/Products/ZMailman/"

>ZMailman</a> for integrating Zope and Mailman.  I consider this a

proof of concept of some of the ideas outlined above.