diff options
| -rw-r--r-- | README.txt | 193 | ||||
| -rw-r--r-- | docs/ACKNOWLEDGMENTS.txt | 252 | ||||
| -rw-r--r-- | docs/ALPHA.txt | 92 | ||||
| -rw-r--r-- | docs/STYLEGUIDE.txt | 151 | ||||
| -rw-r--r-- | gnu-COPYING-GPL (renamed from docs/gnu-COPYING-GPL) | 0 | ||||
| -rw-r--r-- | src/attic/docs/OLD-NEWS.txt (renamed from docs/OLD-NEWS.txt) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/add_members.1 (renamed from docs/man/add_members.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/check_db.1 (renamed from docs/man/check_db.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/check_perms.1 (renamed from docs/man/check_perms.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/clone_member.1 (renamed from docs/man/clone_member.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/find_member.1 (renamed from docs/man/find_member.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/list_members.1 (renamed from docs/man/list_members.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/remove_members.1 (renamed from docs/man/remove_members.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/sync_members.1 (renamed from docs/man/sync_members.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/man/transcheck.1 (renamed from docs/man/transcheck.1) | 0 | ||||
| -rw-r--r-- | src/attic/docs/posting-flow-chart.ps (renamed from docs/posting-flow-chart.ps) | 0 | ||||
| -rw-r--r-- | src/mailman/docs/ACKNOWLEDGMENTS.txt | 250 | ||||
| -rw-r--r-- | src/mailman/docs/ALPHA.txt | 79 | ||||
| -rw-r--r-- | src/mailman/docs/NEWS.txt (renamed from docs/NEWS.txt) | 0 | ||||
| -rw-r--r-- | src/mailman/docs/README.txt | 2 | ||||
| -rw-r--r-- | src/mailman/docs/STYLEGUIDE.txt | 130 |
21 files changed, 479 insertions, 670 deletions
diff --git a/README.txt b/README.txt index d4cf307aa..59e707060 100644 --- a/README.txt +++ b/README.txt @@ -1,184 +1,27 @@ +================================================ Mailman - The GNU Mailing List Management System -Copyright (C) 1998-2009 by the Free Software Foundation, Inc. - -INTRODUCTION - - This is GNU Mailman, a mailing list management system distributed under - the terms of the GNU General Public License (GPL) version 3 or later. The - name of this software is spelled "Mailman" with a leading capital `M' but - with a lower case second `m'. Any other spelling is incorrect. - - Mailman is written in Python, a free object-oriented scripting language. - Python is available for all platforms that Mailman is supported on, which - includes GNU/Linux and most other Unix-like operating systems - (e.g. Solaris, *BSD, MacOSX, etc.). It does not run on Windows, although - web and mail clients on any platform should be able to interact with - Mailman just fine. - - Mailman was originally developed by John Viega. Subsequent development - (through version 1.0b3) was by Ken Manheimer. Further work towards the - 1.0 final release was a group effort, with the core contributors being: - Barry Warsaw, Ken Manheimer, Scott Cotton, Harald Meland, and John Viega. - Version 1.0 and beyond have been primarily maintained by Barry Warsaw with - contributions from many; see the ACKNOWLEDGMENTS file for details. Jeremy - Hylton helped considerably with the Pipermail code in Mailman 2.0. - Mailman 2.1 is now being primarily maintained by Mark Sapiro and Tokio - Kikuchi. Barry Warsaw is the lead developer on Mailman 3. - - The Mailman home page is: - - http://www.list.org - - with mirrors at: - - http://www.gnu.org/software/mailman - http://mailman.sf.net - - You might also be interested in the Mailman wiki at: - - http://wiki.list.org - - Mailman 3.0 requires Python 2.6 or greater, which can be downloaded from: - - http://www.python.org - - -FEATURES - - **Mailman 3.0 is alpha software and some of this information may be out of - date or not currently working. This will improve as the alpha releases - are developed.** - - Mailman has most of the standard features you'd expect in a mailing list - manager, and more: - - - Web based list administration for nearly all tasks. Web based - subscriptions and user configuration management. A customizable "home - page" for each mailing list. - - - Privacy features such as moderation, open and closed list subscription - policies, private membership rosters, and sender-based filters. - - - Automatic web based archiving built-in with support for private and - public archives, and hooks for external archivers. - - - Per-user configuration optional digest delivery for either - MIME-compliant or RFC 1153 style "plain text" digests. - - - Integrated mail/Usenet gateways. - - - Integrated auto-replies. - - - Email commands. - - - Integrated bounce detection within an extensible framework. - - - Integrated spam detection, and MIME-based content filtering. - - - An extensible mail delivery pipeline. - - - Support for virtual domains. - +================================================ -REQUIREMENTS - - The default mail delivery mechanism uses a direct SMTP connection to - whatever mail transport agent you have running on port 25. You can thus - use Mailman with any such MTA, however with certain MTAs (e.g. Exim and - Postfix), Mailman will support thru-the-web creation and removal of - mailing lists. - - Mailman works with any web server that supports CGI/1.1. The HTML it - generates should be friendly to most web browsers and network connections. - - You will need root access on the machine hosting your Mailman installation - in order to complete some of the configuration steps. See the INSTALL.txt - file for details. - - Mailman's web and email user interface should be compatible with just - about any mail reader or web browser, although a mail reader that is MIME - aware will be a big help. You do not need Java, JavaScript, or any other - fancy plugins. - - -FOR MORE INFORMATION - - For information on this alpha release, see docs/ALPHA.txt - - More documentation is available in the docs directory, and on-line (see - below). Installation instructions are contained in the - docs/readmes/INSTALL.txt file. Upgrading information is available in the - docs/readmes/UPGRADING.txt file. See the docs/NEWS.txt file for a list of - changes since version 0.9. - - The online documentation can be found in - - file:admin/www/index.html - - in the directory in which you unpacked Mailman. - - There is an online FAQ maintained by the Mailman community, which contains - a vast amount of information: - - http://www.python.org/cgi-bin/faqw-mm.py - - There is a wiki for more community-driven information: - - http://wiki.list.org - - The wiki includes the online FAQ maintained by the Mailman community, - which contains a vast amount of information: - - http://wiki.list.org/display/DOC/Frequently+Asked+Questions - - As well as links to further documentation: - - http://wiki.list.org/display/DOC/ - - There are also several mailing lists that can be used as resources - to help you get going with Mailman. - - Mailman-Users - An list for users of Mailman, for posting questions or problems - related to installation, use, etc. We'll try to keep the deep - technical discussions off this list. - - http://mail.python.org/mailman/listinfo/mailman-users - - Mailman-Announce - A read-only list for release announcements an other important news. - - http://mail.python.org/mailman/listinfo/mailman-announce - - Mailman-Developers - A list for those of you interested in helping develop Mailman 2's - future direction. This list will contain in-depth technical - discussions. - - http://mail.python.org/mailman/listinfo/mailman-developers - - Mailman-I18N - A list for the discussion of the Mailman internationalization - effort. Mailman 2.1 is fully multi-lingual. - - http://mail.python.org/mailman/listinfo/mailman-i18n +Copyright (C) 1998-2009 by the Free Software Foundation, Inc. - Mailman-Checkins - A read-only list which is an adjunct to the public anonymous CVS - repository. You can stay on the bleeding edge of Mailman development - by subscribing to this list. +This is GNU Mailman, a mailing list management system distributed under the +terms of the GNU General Public License (GPL) version 3 or later. The name of +this software is spelled "Mailman" with a leading capital `M' but with a lower +case second `m'. Any other spelling is incorrect. - http://mail.python.org/mailman/listinfo/mailman-checkins +Mailman is written in Python which is available for all platforms that Mailman +is supported on, including GNU/Linux and most other Unix-like operating +systems (e.g. Solaris, *BSD, MacOSX, etc.). It does not run on Windows, +although web and mail clients on any platform should be able to interact with +Mailman just fine. - The Mailman project is coordinated on SourceForge at +The Mailman home page is: - http://sf.net/projects/mailman + http://www.list.org - You should use SourceForge to report bugs and to upload patches. +and there is a community driven wiki at + http://wiki.list.org - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: +For more information on Mailman, see the above web sites, or the documentation +provided with this software. Start at src/mailman/docs/README.txt. diff --git a/docs/ACKNOWLEDGMENTS.txt b/docs/ACKNOWLEDGMENTS.txt deleted file mode 100644 index 321470388..000000000 --- a/docs/ACKNOWLEDGMENTS.txt +++ /dev/null @@ -1,252 +0,0 @@ -Mailman - The GNU Mailing List Management System -Copyright (C) 1998-2007 by the Free Software Foundation, Inc. -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA - -The following folks are or have been core developers of Mailman (in reverse -alphabetical order): - - Barry Warsaw, Mailman's yappy guard dog - Thomas Wouters, Mailman's Dutch treat - John Viega, Mailman's inventor - Mark Sapiro, Mailman's compulsive responder - Harald Meland, Norse Mailman - Ken Manheimer, Mailman's savior - Tokio Kikuchi, Mailman's weatherman - Scott Cotton, Cookie-Monster - -They can be contacted directly via mailman-cabal@python.org. - -Here is the list of other contributors who have donated large bits of -code, and have assigned copyright for contributions to the FSF: - - Juan Carlos Rey Anaya - Richard Barrett - Stephan Berndts - Norbert Bollow - Ben Gertzfield - Victoriano Giralt - Mads Kiilerich - The Dragon De Monsyne - Les Niles - Terri Oda - Simone Piunno - -Thanks also go to the following people for their important contributions in -other aspects of the Mailman project: - - Brad Knowles - JC Dill - -Thanks also to Dragon for his winning Mailman logo contribution, and -to Terri Oda for the neat shortcut icon and the member documentation. - -Control.com sponsored development of several Mailman 2.1 features, -including topics filters, external membership sources, and initial -virtual mailing list support. My thanks especially to Dan Pierson and -Ken Crater from Control.com. - -Here is the list of other people who have contributed useful ideas, -suggestions, bug fixes, testing, etc., or who have been very helpful -in answering questions on mailman-users. - - David Abrahams - William Ahern - Terry Allen - Jose Paulo Moitinho de Almeida - Sven Anderson - Matthias Andree - Anton Antonov - Mike Avery - Stonewall Ballard - Moreno Baricevic - Jeff Berliner - Stuart Bishop - David Blomquist - Bojan - Søren Bondrup - Grant Bowman - Alessio Bragadini - J. D. Bronson - Stan Bubrouski - Daniel Buchmann - Ben Burnett - Ted Cabeen - Mentor Cana - John Carnes - Julio A. Cartaya - Claudio Cattazzo - Donn Cave - David Champion - Hye-Shik Chang - Eric D. Christensen - Tom G. Christensen - Paul Cox - Stefaniu Criste - Robert Daeley - Ned Dawes - Emilio Delgado - John Dennis - Stefan Divjak - Maximillian Dornseif - Fred Drake - Maxim Dzumanenko - Piarres Beobide Egaña - Rob Ellis - Kerem Erkan - Fil - Patrick Finnerty - Bob Fleck - Erik Forsberg - Darrell Fuhriman - Robert Garrigós - Carson Gaspar - Pascal GEORGE - Vadim Getmanshchuk - David Gibbs - Dmitri I GOULIAEV - Terry Grace - Federico Grau - Pekka Haavisto - David Habben - Stig Hackvan - Jeff Hahn - Terry Hardie - Paul Hebble - Tollef Fog Heen - Peer Heinlein - James Henstridge - Walter Hop - Bert Hubert - Henny Huisman - Jeremy Hylton - Ikeda Soji - Rostyk Ivantsiv - Ron Jarrell - Matthias Juchem - Tamito KAJIYAMA - Nino Katic - SHIGENO Kazutaka - Ashley M. Kirchner - Matthias Klose - Harald Koch - Patrick Koetter - Eddie Kohler - Chris Kolar - Uros Kositer - Andrew Kuchling - Ricardo Kustner - L'homme Moderne - Sylvain Langlade - Ed Lau - J C Lawrence - Greg Lindahl - Christopher P. Lindsey - Martin von Loewis - Dario Lopez-Kästen - Tanner Lovelace - Jay Luker - Gergely Madarasz - Luca Maranzano - John A. Martin - Andrew Martynov - Jason R. Mastaler - Michael Mclay - Michael Meltzer - Marc MERLIN - Nigel Metheringham - Dan Mick - Garey Mills - Martin Mokrejs - Michael Fischer v. Mollard - David Martínez Moreno - Dirk Mueller - Jonas Muerer - Erik Myllymaki - Balazs Nagy - Moritz Naumann - Dale Newfield - Hrvoje Niksic - Les Niles - Mike Noyes - David B. O'Donnell - Timothy O'Malley - "office" - Dan Ohnesorg - Gerald Oskoboiny - Eva Österlind - Toni Panadès - Jon Parise - Chris Pepper - Tim Peters - Joe Peterson - PieterB - Rodolfo Pilas - Skye Poier - Martin Pool - Don Porter - Francesco Potortì - Bob Puff - Michael Ranner - John Read - Sean Reifschneider - Christian Reis - Ademar de Souza Reis, Jr. - Bernhard Reiter - Stephan Richter - Tristan Roddis - Heiko Rommel - Luigi Rosa - Guido van Rossum - Nicholas Russo - Chris Ryan - Cabel Sasser - Bartosz Sawicki - Kai Schaetzl - Karoly Segesdi - Gleydson Mazioli da Silva - Pasi Sjöholm - Chris Snell - Mikhail Sobolev - Greg Stein - Dale Stimson - Students of HIT <mailman-cn@mail.cs.hit.edu.cn> - Szabolcs Szigeti - Vizi Szilard - David T-G - Owen Taylor - Danny Terweij - Jim Tittsler - Todd (Freedom Lover) - Roger Tsang - Chuq Von Rospach - Jens Vagelpohl - Valia V. Vaneeva - Anti Veeranna - Todd Vierling - Bill Wagner - Greg Ward - Mark Weaver - Kathleen Webb - Florian Weimer - Ousmane Wilane - Dan Wilder - Seb Wills - Dai Xiaoguang - Ping Yeh - YASUDA Yukihiro - Michael Yount - Blair Zajac - Mikhail Zabaluev - Noam Zeilberger - Daniel Zeiss - Todd Zullinger - -And everyone else on mailman-developers@python.org and -mailman-users@python.org! Thank you, all. - - - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: diff --git a/docs/ALPHA.txt b/docs/ALPHA.txt deleted file mode 100644 index dec6a01a7..000000000 --- a/docs/ALPHA.txt +++ /dev/null @@ -1,92 +0,0 @@ -Mailman - The GNU Mailing List Management System -Copyright (C) 2008-2009 by the Free Software Foundation, Inc. -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA - -ALPHA RELEASE - - The Mailman 3 alpha releases are being provided to give developers and - other interested people an early look at the next major version. As such, - many things may not work yet. Your participation is encouraged. Your - feedback and contributions are welcome. Please submit bug reports on the - Mailman bug tracker at - - https://bugs.launchpad.net/mailman - - or on the mailman-developers mailing list. - - -USING THE ALPHA - - Python 2.6 is required. It can either be the default 'python' on your - $PATH or it can be accessible via the 'python2.6' binary. See - http://www.python.org for details on getting Python 2.6. - - Mailman 3 is now based on the zc.buildout infrastructure, which greatly - simplifies building and testing Mailman. - - This version of Mailman depends on an unofficial branch of the lazr.config - package. This branch adds a number of useful features and fixes some - bugs, but it is still under review and not yet part of the official - package. Start by checking out this unofficial branch: - - % cd wherever - % bzr branch lp:~barry/lazr.config/megamerge - - Now you need to edit Mailman's buildout.cfg file. Look for the 'develop' - line under the [buildout] section. Change the path to the megamerge - package to point to the location of your checked out branch above. - - You will need the gettext package (specifically, the msgfmt(1) command) in - order to build the I18N message catalogs. If you're missing this command, - it is known that the digests.txt test will fail. - - You do not need anything other than Python 2.6 and an internet connection - to get all the other Mailman 3 dependencies. Here are the commands to - build everything: - - % python2.6 bootstrap.py - % bin/buildout - - Now you can run the test suite via: - - % bin/test - - You should see no failures. - - At this point you can read the doctests by looking in all the 'doc' - directories under the 'mailman' package. Doctests are documentation - first, so they should give you a pretty good idea how various components - of Mailman 3 works. - - What, you actually want to /run/ Mailman 3? Oh well, if you insist. You - will need to set up a configuration file to override the defaults and set - things up for your environment. Currently Mailman 3 is configured with a - bastard mix of the old configuration system and lazr.config, which is an - ini-style configuration system. Eventually all configuration will be - converted to lazr.config. - - For now though, start by looking through src/mailman/config/schema.cfg. - Create a file for your overrides; it can be called anything and can live - anywhere, but I like to call it 'mailman.cfg'. For any value in - schema.cfg you want to override, just add a section header (the - square-bracketed names) and then the 'key: value' pair you want to - override. - - You will need to pass the -C flag to any bin command you want to invoke, - pointing it at your mailman.cfg file. The next release will make this - simpler by searching some default locations. - - You can use the create_list, remove_list, list_lists, add_members, and - list_members to set up and populate some mailing lists. You of course - also need to use mailmanctl to start the queue runners, and then you can - use the inject command to put some messages into the queue. For the most - part, they ought to get delivered <wink>. - - Please note that the web u/i does /not/ work yet. - - - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: diff --git a/docs/STYLEGUIDE.txt b/docs/STYLEGUIDE.txt deleted file mode 100644 index d4a7bc527..000000000 --- a/docs/STYLEGUIDE.txt +++ /dev/null @@ -1,151 +0,0 @@ -Python coding style guide for Mailman -Copyright (C) 2002-2009 Barry A. Warsaw - -NOTE: The canonical version of this style guide can be found at: - - http://barry.warsaw.us/software/STYLEGUIDE.txt - -This document contains a style guide for Python programming, as used in -Mailman. In general, Guido van Rossum's style guide should be taken as a -basis, as embodied in PEP 8: - - http://www.python.org/peps/pep-0008.html - -however, my (Barry Warsaw's) personal preferences differ from Guido's in a few -places. "When in Rome..." should apply meaning, when coding stuff for Python, -Guido's style should rule, however when coding for Mailman, I'd like to see my -preferences used instead. - -Remember rule #1, A Foolish Consistency is the Hobgoblin of Little Minds. -That said, here's a quick outline of where my preferences depart from PEP 8. - -- After file comments (e.g. license block), add a __metaclass__ definition so - that (in Python 2.x) all classes will be new-style. Following that, add an - __all__ section that names, one-per-line, all the public names exported by - this module. - -- Imports are always put at the top of the file, just after any module - comments and docstrings, and before module globals and constants, but after - any __future__ imports, or __metaclass__ and __all__ definitions. - - Imports should be grouped, with the order being: - - 1. standard library imports - 2. related major package imports (e.g. all email package imports next) - 3. application specific imports - - From-imports should follow non-from imports. Dotted imports should follow - non-dotted imports. Non-dotted imports should be grouped by increasing - length, while dotted imports should be grouped alphabetically. - -- In general, there should be at most one class per module, if the module - contains class definitions. If it's a module of functions, that's fine, - group them as common sense dictates. A class-containing module can also - contain some helper functions, but it's best to keep these non-public by not - including them in the __all__ section. - - Give the class and the module the same name, differing only by case as PEP 8 - recommends. E.g. - - from mailman.parser import Parser - -- When importing a class from a class-containing module, it's usually - okay to spell this - - from myclass import MyClass - from foo.bar.yourclass import YourClass - - If this spelling causes name clashes, then spell them - - import myclass - import foo.bar.yourclass - - and use "myclass.MyClass" - - You can also use 'import...as' to rename a clashing symbol. - -- Right hanging comments are discouraged, in favor of preceding comments. - E.g. bad: - - foo = blarzigop(bar) # if you don't blarzigop it, it'll shlorp - - Good: - - # If you don't blarzigop it, it'll shlorp. - foo = blarzigop(bar) - - Comments should always be complete sentences, with proper capitalization and - full stops at the end. - -- Major sections of code in a module should be separated by line feed - characters (e.g. ^L -- that's a single character control-L not two - characters). This helps with Emacs navigation. - - Always put a ^L before module-level functions, before class definitions, - before big blocks of constants which follow imports, and any place else that - would be convenient to jump to. Always put two blank lines before a ^L. - -- Put two blank lines between any top level construct or block of code - (e.g. after import blocks). Put only one blank line between methods in a - class. No blank lines between the class definition and the first method in - the class. No blank lines between a class/method and its docstrings. - -- Try to minimize the vertical whitespace in a class. If you're inclined to - separate stanzas of code for readability, consider putting a comment in - describing what the next stanza's purpose is. Don't put stupid or obvious - comments in just to avoid vertical whitespace though. - -- Unless internal quote characters would mess things up, the general rule is - that single quotes should be used for short strings, double quotes for - triple-quoted multi-line strings and docstrings. E.g. - - foo = 'a foo thing' - warn = "Don't mess things up" - notice = """Our three chief weapons are: - - surprise - - deception - - an almost fanatical devotion to the pope - """ - -- Write docstrings for modules, functions, classes, and methods. Docstrings - can be omitted for special methods (e.g. __init__() or __str__()) where the - meaning is obvious. - -- PEP 257 describes good docstrings conventions. Note that most importantly, - the """ that ends a multiline docstring should be on a line by itself, e.g.: - - """Return a foobang - - Optional plotz says to frobnicate the bizbaz first. - """ - -- For one liner docstrings, keep the closing """ on the same line. - -- <> is strongly preferred over != (Sadly, Python is making this harder to - follow and it cannot be followed for Python 3). - -- fill-column for docstrings should be 78. - -- When testing the emptiness of sequences, use "if len(seq) == 0" instead of - relying on the falseness of empty sequences. However, if a variable can be - one of several false values, it's okay to just use "if seq", though a - preceding comment is usually in order. - -- Always decide whether a class's methods and instance variables should be - public or non-public. - - Single leading underscores are generally preferred for non-public - attributes. Use double leading underscores only in classes designed for - inheritance to ensure that truly private attributes will never name clash. - - Public attributes should have no leading or trailing underscores unless they - conflict with reserved words, in which case, a single trailing underscore is - preferable to a leading one, or a corrupted spelling, e.g. class_ rather - than klass. - - - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: diff --git a/docs/gnu-COPYING-GPL b/gnu-COPYING-GPL index 3912109b5..3912109b5 100644 --- a/docs/gnu-COPYING-GPL +++ b/gnu-COPYING-GPL diff --git a/docs/OLD-NEWS.txt b/src/attic/docs/OLD-NEWS.txt index c87635640..c87635640 100644 --- a/docs/OLD-NEWS.txt +++ b/src/attic/docs/OLD-NEWS.txt diff --git a/docs/man/add_members.1 b/src/attic/docs/man/add_members.1 index d442a2b66..d442a2b66 100644 --- a/docs/man/add_members.1 +++ b/src/attic/docs/man/add_members.1 diff --git a/docs/man/check_db.1 b/src/attic/docs/man/check_db.1 index 28a3b8149..28a3b8149 100644 --- a/docs/man/check_db.1 +++ b/src/attic/docs/man/check_db.1 diff --git a/docs/man/check_perms.1 b/src/attic/docs/man/check_perms.1 index 76966a87c..76966a87c 100644 --- a/docs/man/check_perms.1 +++ b/src/attic/docs/man/check_perms.1 diff --git a/docs/man/clone_member.1 b/src/attic/docs/man/clone_member.1 index 35148f6af..35148f6af 100644 --- a/docs/man/clone_member.1 +++ b/src/attic/docs/man/clone_member.1 diff --git a/docs/man/find_member.1 b/src/attic/docs/man/find_member.1 index 9d76bf5db..9d76bf5db 100644 --- a/docs/man/find_member.1 +++ b/src/attic/docs/man/find_member.1 diff --git a/docs/man/list_members.1 b/src/attic/docs/man/list_members.1 index cbf338a40..cbf338a40 100644 --- a/docs/man/list_members.1 +++ b/src/attic/docs/man/list_members.1 diff --git a/docs/man/remove_members.1 b/src/attic/docs/man/remove_members.1 index 69ed545d6..69ed545d6 100644 --- a/docs/man/remove_members.1 +++ b/src/attic/docs/man/remove_members.1 diff --git a/docs/man/sync_members.1 b/src/attic/docs/man/sync_members.1 index b185ae3c1..b185ae3c1 100644 --- a/docs/man/sync_members.1 +++ b/src/attic/docs/man/sync_members.1 diff --git a/docs/man/transcheck.1 b/src/attic/docs/man/transcheck.1 index 6e16a10f8..6e16a10f8 100644 --- a/docs/man/transcheck.1 +++ b/src/attic/docs/man/transcheck.1 diff --git a/docs/posting-flow-chart.ps b/src/attic/docs/posting-flow-chart.ps index e8d47e27c..e8d47e27c 100644 --- a/docs/posting-flow-chart.ps +++ b/src/attic/docs/posting-flow-chart.ps diff --git a/src/mailman/docs/ACKNOWLEDGMENTS.txt b/src/mailman/docs/ACKNOWLEDGMENTS.txt new file mode 100644 index 000000000..a79794844 --- /dev/null +++ b/src/mailman/docs/ACKNOWLEDGMENTS.txt @@ -0,0 +1,250 @@ +================================================ +Mailman - The GNU Mailing List Management System +================================================ + +Copyright (C) 1998-2009 by the Free Software Foundation, Inc. +51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + +The following folks are or have been core developers of Mailman (in reverse +alphabetical order): + +* Barry Warsaw, Mailman's yappy guard dog +* Mark Sapiro, Mailman's compulsive responder +* Tokio Kikuchi, Mailman's weatherman +* John Viega, Mailman's inventor +* Thomas Wouters, Mailman's Dutch treat +* Harald Meland, Norse Mailman +* Ken Manheimer, Mailman's savior +* Scott Cotton, Cookie-Monster + +The Mailman Steering Committee can be contacted directly via +mailman-cabal@python.org + +Here is the list of other contributors who have donated large bits of +code, and have assigned copyright for contributions to the FSF: + +* Juan Carlos Rey Anaya +* Richard Barrett +* Stephan Berndts +* Norbert Bollow +* Ben Gertzfield +* Victoriano Giralt +* Mads Kiilerich +* The Dragon De Monsyne +* Les Niles +* Terri Oda +* Simone Piunno + +Thanks also go to the following people for their important contributions in +other aspects of the Mailman project: + +* Brad Knowles +* JC Dill +* Clytie Siddall + +Thanks also to Dragon for his winning Mailman logo contribution, and to Terri +Oda for the neat shortcut icon and the member documentation. + +Control.com sponsored development of several Mailman 2.1 features, including +topics filters, external membership sources, and initial virtual mailing list +support. My thanks especially to Dan Pierson and Ken Crater from Control.com. + +Here is the list of other people who have contributed useful ideas, +suggestions, bug fixes, testing, etc., or who have been very helpful in +answering questions on mailman-users. Please let me know if anybody's been +left off the list! + +* David Abrahams +* William Ahern +* Terry Allen +* Jose Paulo Moitinho de Almeida +* Sven Anderson +* Matthias Andree +* Anton Antonov +* Mike Avery +* Stonewall Ballard +* Moreno Baricevic +* Jeff Berliner +* Stuart Bishop +* David Blomquist +* Bojan +* Søren Bondrup +* Grant Bowman +* Alessio Bragadini +* J. D. Bronson +* Stan Bubrouski +* Daniel Buchmann +* Ben Burnett +* Ted Cabeen +* Mentor Cana +* John Carnes +* Julio A. Cartaya +* Claudio Cattazzo +* Donn Cave +* David Champion +* Hye-Shik Chang +* Eric D. Christensen +* Tom G. Christensen +* Paul Cox +* Stefaniu Criste +* Robert Daeley +* Ned Dawes +* Emilio Delgado +* John Dennis +* Stefan Divjak +* Maximillian Dornseif +* Fred Drake +* Maxim Dzumanenko +* Piarres Beobide Egaña +* Rob Ellis +* Kerem Erkan +* Fil +* Patrick Finnerty +* Bob Fleck +* Erik Forsberg +* Darrell Fuhriman +* Robert Garrigós +* Carson Gaspar +* Pascal GEORGE +* Vadim Getmanshchuk +* David Gibbs +* Dmitri I GOULIAEV +* Terry Grace +* Federico Grau +* Pekka Haavisto +* David Habben +* Stig Hackvan +* Jeff Hahn +* Terry Hardie +* Paul Hebble +* Tollef Fog Heen +* Peer Heinlein +* James Henstridge +* Walter Hop +* Bert Hubert +* Henny Huisman +* Jeremy Hylton +* Ikeda Soji +* Rostyk Ivantsiv +* Ron Jarrell +* Matthias Juchem +* Tamito KAJIYAMA +* Nino Katic +* SHIGENO Kazutaka +* Ashley M. Kirchner +* Matthias Klose +* Harald Koch +* Patrick Koetter +* Eddie Kohler +* Chris Kolar +* Uros Kositer +* Andrew Kuchling +* Ricardo Kustner +* L'homme Moderne +* Sylvain Langlade +* Ed Lau +* J C Lawrence +* Greg Lindahl +* Christopher P. Lindsey +* Martin von Loewis +* Dario Lopez-Kästen +* Tanner Lovelace +* Jay Luker +* Gergely Madarasz +* Luca Maranzano +* John A. Martin +* Andrew Martynov +* Jason R. Mastaler +* Michael Mclay +* Michael Meltzer +* Marc MERLIN +* Nigel Metheringham +* Dan Mick +* Garey Mills +* Martin Mokrejs +* Michael Fischer v. Mollard +* David Martínez Moreno +* Dirk Mueller +* Jonas Muerer +* Erik Myllymaki +* Balazs Nagy +* Moritz Naumann +* Dale Newfield +* Hrvoje Niksic +* Les Niles +* Mike Noyes +* David B. O'Donnell +* Timothy O'Malley +* "office" +* Dan Ohnesorg +* Gerald Oskoboiny +* Eva Österlind +* Toni Panadès +* Jon Parise +* Chris Pepper +* Tim Peters +* Joe Peterson +* PieterB +* Rodolfo Pilas +* Skye Poier +* Martin Pool +* Don Porter +* Francesco Potortì +* Bob Puff +* Michael Ranner +* John Read +* Sean Reifschneider +* Christian Reis +* Ademar de Souza Reis, Jr. +* Bernhard Reiter +* Stephan Richter +* Tristan Roddis +* Heiko Rommel +* Luigi Rosa +* Guido van Rossum +* Nicholas Russo +* Chris Ryan +* Cabel Sasser +* Bartosz Sawicki +* Kai Schaetzl +* Karoly Segesdi +* Gleydson Mazioli da Silva +* Pasi Sjöholm +* Chris Snell +* Mikhail Sobolev +* Greg Stein +* Dale Stimson +* Students of HIT <mailman-cn@mail.cs.hit.edu.cn> +* Szabolcs Szigeti +* Vizi Szilard +* David T-G +* Owen Taylor +* Danny Terweij +* Jim Tittsler +* Todd (Freedom Lover) +* Roger Tsang +* Chuq Von Rospach +* Jens Vagelpohl +* Valia V. Vaneeva +* Anti Veeranna +* Todd Vierling +* Bill Wagner +* Greg Ward +* Mark Weaver +* Kathleen Webb +* Florian Weimer +* Ousmane Wilane +* Dan Wilder +* Seb Wills +* Dai Xiaoguang +* Ping Yeh +* YASUDA Yukihiro +* Michael Yount +* Blair Zajac +* Mikhail Zabaluev +* Noam Zeilberger +* Daniel Zeiss +* Todd Zullinger + +And everyone else on mailman-developers@python.org and +mailman-users@python.org! Thank you, all. diff --git a/src/mailman/docs/ALPHA.txt b/src/mailman/docs/ALPHA.txt new file mode 100644 index 000000000..59ff59b28 --- /dev/null +++ b/src/mailman/docs/ALPHA.txt @@ -0,0 +1,79 @@ +================================================ +Mailman - The GNU Mailing List Management System +================================================ + +Copyright (C) 2008-2009 by the Free Software Foundation, Inc. +51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + + +ALPHA RELEASE +============= + +The Mailman 3 alpha releases are being provided to give developers and other +interested people an early look at the next major version. As such, some +things may not work yet. Your participation is encouraged. Your feedback and +contributions are welcome. Please submit bug reports on the Mailman bug +tracker at https://bugs.launchpad.net/mailman though you will currently need +to have a login on Launchpad to do so. You can also send email to the +mailman-developers mailing list. + + +USING THE ALPHA +=============== + +Python 2.6 is required. It can either be the default 'python' on your $PATH +or it can be accessible via the 'python2.6' binary. See http://www.python.org +for details on getting Python 2.6. + +Mailman 3 is now based on the `zc.buildout`_ infrastructure, which greatly +simplifies building and testing Mailman. + +You will need the gettext package (specifically, the msgfmt(1) command) in +order to build the I18N message catalogs. If you're missing this command, +it is known that the digests.txt test will fail. + +You do not need anything other than Python 2.6 and an internet connection +to get all the other Mailman 3 dependencies. Here are the commands to +build everything:: + + % python2.6 bootstrap.py + % bin/buildout + +Now you can run the test suite via:: + + % bin/test + +You should see no failures. + +At this point you can read the doctests by looking in all the 'doc' +directories under the 'mailman' package. Doctests are documentation +first, so they should give you a pretty good idea how various components +of Mailman 3 works. + +What, you actually want to *run* Mailman 3? Oh well, if you insist. You +will need to set up a configuration file to override the defaults and set +things up for your environment. Mailman is configured via the `lazr.config`_ +package which is really just a fancy ini-style configuration system. + +For now though, start by looking through ``src/mailman/config/schema.cfg``. +Create a file for your overrides; it can be called anything and can live +anywhere, but I like to call it ``mailman.cfg``. For any value in +``schema.cfg`` you want to override, just add a section header (the +square-bracketed names) and then the key/value pair you want to override. + +You will need to pass the ``-C`` flag to any bin command you want to invoke, +pointing it at your ``mailman.cfg`` file. Or you can set the environment +variable ``$MAILMAN_CONFIG_FILE`` to point to your configuration file. Future +versions will look in some common locations. + +You can use the ``bin/mailman`` script to create and remove mailing lists, +display all the existing mailing lists, subscribe members, etc. Try +``bin/mailman --help`` for details. You can still use the ``bin/mailmanctl`` +script to start the queue runners. + +Please note that the web u/i does **not** work yet. Contributions are +welcome! + + +.. _`zc.buildout`: http://pypi.python.org/pypi/zc.buildout +.. _`lazr.config`: http://pypi.python.org/pypi/lazr.config diff --git a/docs/NEWS.txt b/src/mailman/docs/NEWS.txt index a3fc04d31..a3fc04d31 100644 --- a/docs/NEWS.txt +++ b/src/mailman/docs/NEWS.txt diff --git a/src/mailman/docs/README.txt b/src/mailman/docs/README.txt index 72794f111..d42da8e9c 100644 --- a/src/mailman/docs/README.txt +++ b/src/mailman/docs/README.txt @@ -76,6 +76,8 @@ lists and archives, etc., are available at: http://www.list.org/help.html +For more information about the alpha releases, see `ALPHA.txt`_. + Requirements ============ diff --git a/src/mailman/docs/STYLEGUIDE.txt b/src/mailman/docs/STYLEGUIDE.txt new file mode 100644 index 000000000..f95e949eb --- /dev/null +++ b/src/mailman/docs/STYLEGUIDE.txt @@ -0,0 +1,130 @@ +================================================ +Mailman - The GNU Mailing List Management System +================================================ + +Copyright (C) 2002-2009 Barry A. Warsaw + + +Python coding style guide for GNU Mailman +========================================= + +*NOTE*: The canonical version of this style guide can be found at: + +http://barry.warsaw.us/software/STYLEGUIDE.txt + +This document contains a style guide for Python programming, as used in GNU +Mailman. `PEP 8`_ is the basis for this style guide so it's recommendations +should be followed except for the differences outlined here. + +* After file comments (e.g. license block), add a ``__metaclass__`` definition + so that (in Python 2.x) all classes will be new-style. Following that, add + an ``__all__`` section that names, one-per-line, all the public names + exported by this module. For Python 2.6 code, you should enable absolute + imports and unicode literals. See the `GNU Mailman Python template`_ as an + example. + +* Imports are always put at the top of the file, just after any module + comments and docstrings, and before module globals and constants, but after + any ``__future__`` imports, or ``__metaclass__`` and ``__all__`` + definitions. + + Imports should be grouped, with the order being: + + 1. non-from imports for standard and third party libraries + 2. non-from imports from the application + 3. from-imports from the standard and third party libraries + 4. from-imports from the application + + From-imports should follow non-from imports. Dotted imports should follow + non-dotted imports. Non-dotted imports should be grouped by increasing + length, while dotted imports should be grouped alphabetically. + +* In general, there should be one class per module. Keep files small, but + it's okay to group related code together. List everything exported from the + module in the ``__all__``. + +* Right hanging comments are discouraged, in favor of preceding comments. + E.g. bad:: + + foo = blarzigop(bar) # if you don't blarzigop it, it'll shlorp + + Good:: + + # If you don't blarzigop it, it'll shlorp. + foo = blarzigop(bar) + + Comments should always be complete sentences, with proper capitalization and + full stops at the end. + +* Major sections of code in a module should be separated by line feed + characters (e.g. ``^L`` -- that's a single character control-L not two + characters). This helps with Emacs navigation. + + Always put a ``^L`` before module-level functions, before class definitions, + before big blocks of constants which follow imports, and any place else that + would be convenient to jump to. Always put two blank lines before a ``^L``. + +* Put two blank lines between any top level construct or block of code + (e.g. after import blocks). Put only one blank line between methods in a + class. No blank lines between the class definition and the first method in + the class. No blank lines between a class/method and its docstrings. + +* Try to minimize the vertical whitespace in a class or function. If you're + inclined to separate stanzas of code for readability, consider putting a + comment in describing what the next stanza's purpose is. Don't put stupid + or obvious comments in just to avoid vertical whitespace though. + +* Unless internal quote characters would mess things up, the general rule is + that single quotes should be used for short strings, double quotes for + triple-quoted multi-line strings and docstrings. E.g.:: + + foo = 'a foo thing' + warn = "Don't mess things up" + notice = """Our three chief weapons are: + - surprise + - deception + - an almost fanatical devotion to the pope + """ + +* Write docstrings for modules, functions, classes, and methods. Docstrings + can be omitted for special methods (e.g. __init__() or __str__()) where the + meaning is obvious. + +* PEP 257 describes good docstrings conventions. Note that most importantly, + the """ that ends a multiline docstring should be on a line by itself, e.g.:: + + """Return a foobang + + Optional plotz says to frobnicate the bizbaz first. + """ + +* For one liner docstrings, keep the closing """ on the same line. + +* While ``<>`` is strongly preferred over ``!=``, Guido has pronounced that + the latter is the standard spelling. We could invoke + ``from __future__ import barry_as_FLUFL`` but we'll suck it up and begin the + switch to the finger twister. + +* ``fill-column`` for docstrings should be 78. + +* When testing the emptiness of sequences, use ``if len(seq) == 0`` instead of + relying on the falseness of empty sequences. However, if a variable can be + one of several false values, it's okay to just use ``if seq``, though a + preceding comment is usually in order. + +* Always decide whether a class's methods and instance variables should be + public or non-public. + + Single leading underscores are generally preferred for non-public + attributes. Use double leading underscores only in classes designed for + inheritance to ensure that truly private attributes will never name clash. + These should be rare. + + Public attributes should have no leading or trailing underscores unless they + conflict with reserved words, in which case, a single trailing underscore is + preferable to a leading one, or a corrupted spelling, e.g. ``class_`` rather + than ``klass``. + + +.. `PEP 8`: http://www.python.org/peps/pep-0008.html +.. `GNU Mailman Python template`: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/annotate/head%3A/template.py |