1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
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 freenode.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.
|
