Mailman 3 May 2007 - Mailman-Developers

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 01 Jun '07

01 Jun '07

Thanks John, I had been hoping to avoid command line calls. However, I'm probably just putting unnecessary obstacles up, so unless anybody advises against it I'm going to use subprocess to call the scripts I have to and leave it at that. Ben ----- Original Message ---- From: John Dennis <jdennis(a)redhat.com> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: Lennon Day-Reynolds <lennon(a)reed.edu>; mailman-developers(a)python.org Sent: Thursday, 24 May, 2007 6:21:42 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers On Thu, 2007-05-24 at 09:10 -0700, Ben Sims wrote: > Regarding the Python APIs, I wondered if there is any documentation available? At the moment I am going over the source, which is a bit heavy going. > > For example, I am having trouble working out if it is possible to create a new list from the Python modules directly? > > Any pointers to the right docs here would be appreciated. Your best bet might be to look at the command line interfaces under the /bin directory in the source tarball. For the case cited you'll want to look at bin/newlist. -- John Dennis <jdennis(a)redhat.com> ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

3 2

Moving to Bazaar and Launchpad
by Barry Warsaw 29 May '07

29 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Several weeks ago I asked whether it was time to move the Mailman source code from Subversion to a distribute version control system (dvcs). I appreciate all the great feedback that people provided, both on the public list and in private email. It's clear that moving to a dvcs has widespread support, and that people are willing to learn a new version control system in order to gain the benefits of a dvcs. Several people suggested that we look at Mercurial and git, as well as some other dvcs's. At the time I narrowed the choices to Mercurial and Bazaar because I wanted to stick with a Python-based version control system. Well, I've spent some time playing with both systems, talking to folks, and thinking about the move. Either dvcs would probably serve our needs and either would give us advantages over Subversion. However, I have chosen Bazaar, with hosting on Launchpad. In summary, the advanced branch hosting support offered by Launchpad, combined with the ability to get first hand help for any future problems or wishlists, swayed me to Bazaar. I didn't find anything compelling enough about Mercurial to make a difference, although I'm sure it's a fine dvcs. So, I am going to begin the process of moving our Subversion repository to Bazaar-on-Launchpad. My target date for pulling the switch is Friday June 22nd, 2007. In preparation, I've merged my exp-elixir-branch to the trunk. I've had enough success with this to feel confident that the SQLAlchemy/ Elixir approach is going to work pretty well, and I want to reduce the number of branches we have to import into Launchpad. The Subversion repository will remain available on SourceForge, but after flag day, it will be read only. I've written a wiki page about the switch, available here: http://wiki.list.org/display/DEV/MailmanOnLaunchpad and there are still a few things to work out, but I think we're quite close. Please read that wiki page and let me know if you have any questions. In the meantime, if you currently have write access to the Mailman Subversion repository, please register on Launchpad, request membership in the mailman-coders team, and send me a private email with your Launchpad user id. I'll go through and start approving committers so we'll have everything in place when it's time to finalize the switch. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRly4ZXEjvBPtnXfVAQJfjAQAsHEQYbNyonsFwjTGVa28ZWkSyT/1BLiq V4kqKfLK3/ZVE+6HoWDJ5heHWmbcfyHAXAdz1bR+WvUGdmrRkAkU90848MdUB3p/ k+49VHhux+N541ZENpEXXbIAu0Lu1rVbGMbIT9iMoOhGSHbbUMvkl6gsPc1nIJJ/ llTBJfB5nAU= =dSGG -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 24 May '07

24 May '07

Thanks Lennon, What you describe below seems to be very close to what I am attempting to do, other than that I have been trying to avoid the cron/SSH stuff. I've managed to get basic implemetations of the SOAP stuff working, with a PHP SOAP client talking to a ZSI SOAP server on the Mailman box. Regarding the Python APIs, I wondered if there is any documentation available? At the moment I am going over the source, which is a bit heavy going. For example, I am having trouble working out if it is possible to create a new list from the Python modules directly? Any pointers to the right docs here would be appreciated. Regards, Benjamin ----- Original Message ---- From: Lennon Day-Reynolds <lennon(a)reed.edu> To: mailman-developers(a)python.org Sent: Monday, 21 May, 2007 10:59:52 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: > [...] > I wonder if there isn't a cleaner way to integrate PHP and Python. > Does anybody know? Or is some form of IPC really the only way to go? > > Writing command line interfaces to provide the functionality you want > should not be difficult at all, if you are comfortable writing Python. I've built applications that manipulate Mailman data using both the internal Python APIs and the command-line scripts, and I can say that both have their pleasantries and annoyances in about equal share. Generally, the command-line tools are "good enough," and are certainly easier to expose to anything not written in Python. However, the argument handling is just different enough between tools to make a totally general bridge difficult to write without special cases for each action (add/list/remove member, add/show/delete list, etc.). We have Perl and Ruby apps using the CLI tools to manipulate list membership, though most run either under cron or an interactive SSH session to the Mailman server. The Python APIs can be faster, and certainly give you more powerful (read: unrestricted) access to list data. For operations over large numbers of lists, though, the unmarshalling of list pickles seems to be the limiting factor, not the Python startup overhead. One such all-Python application I've developed for use here at Reed uses web.py and the Mailman Python APIs to expose a quick 'opt-in' interface to a subset of our campus mailing lists. We rely on our LDAP directory and web single-sign-on infrastructure to simplify the subscription process: basically, after completing SSO auth, users can simply check the subscription box next to each list name, and be automatically added to (or removed from) it. I'm eagerly looking forward to MM3 (or at least the SQLAlchemy branch) making much of the hackish local customization work I've done unnecessary. The XML-RPC interface sounds interesting, too, though I don't know that it will really offer enough to prompt a rewrite of all our command-line driven add-ons. Lennon Day-Reynolds Systems Programmer Reed College -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUghIRtirLnfvQskRAoaMAKCpAwxGPFJzXyEMgTJDLyLo7Hs+uwCdHP/l HMJgJcyut94SzbgOC9IAcRo= =77oH -----END PGP SIGNATURE----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/benjaminsims%40ya… Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

2 1

Re: [Mailman-Developers] Looking for a Developer for a MailMan module
by Nick Ashton-Hart 23 May '07

23 May '07

We are currently running 2.1.9 cp2. On 23/05/07, Torsten Schlabach <TSchlabach(a)gmx.net> wrote: > Hi Nick! > > If nobody stepped up so far, I might be interested, depending on the urgency ... > > For what version of Mailman would you need it, 2.1.x or 2.2? > > Regards, > Torsten > > -------- Original-Nachricht -------- > Datum: Tue, 22 May 2007 19:22:03 +0100 > Von: Nick Ashton-Hart <nick.ashton-hart(a)icann.org> > An: mailman-developers(a)python.org > Betreff: [Mailman-Developers] Looking for a Developer for a MailMan module > > > Dear MailMan developers: > > > > Barry suggested that I contact you all in reference to the following > > and see if any of you are interested. > > > > I'm looking to contract a developer to code a module for MailMan, so > > that MailMan can interface to a machine translation API provided by > > SYSTRAN, such that inbound emails would get translated into the > > default language chosen by the user individually from the MailMan > > options page. > > > > They would receive as the default output in the body of the email the > > translated text, with the original text as an attachment. Any > > attached files would be left untouched but passed through as defined > > by regular mailman settings. > > > > Of course this would be a paying engagement. > > > > -- > > Regards, > > > > Nick Ashton-Hart > > Director, At-Large > > ICANN > > PO Box 32160 > > London N4 2XY > > United Kingdom > > Main Tel: +44 (20) 8800-1011] > > USA Tel: +1 (202) 657-5460 > > Fax: +44 (20) 7681-3135 > > mobile: +44 (7774) 932798 > > email: nick.ashton-hart(a)icann.org > > Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / > > Skype: nashtonhart > > Online Bio: https://www.linkedin.com/in/ashtonhart > > > > > > > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers(a)python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > > Searchable Archives: > > http://www.mail-archive.com/mailman-developers%40python.org/ > > Unsubscribe: > > http://mail.python.org/mailman/options/mailman-developers/tschlabach%40gmx.… > > > > Security Policy: > > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- -- Regards, Nick Ashton-Hart PO Box 32160 London N4 2XY United Kingdom UK Tel: +44 (20) 8800-1011 USA Tel: +1 (202) 657-5460 Fax: +44 (20) 7681-3135 mobile: +44 (7774) 932798 Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / Skype: nashtonhart Online Bio: https://www.linkedin.com/in/ashtonhart

1 0

Looking for a Developer for a MailMan module
by Nick Ashton-Hart 23 May '07

23 May '07

Dear MailMan developers: Barry suggested that I contact you all in reference to the following and see if any of you are interested. I'm looking to contract a developer to code a module for MailMan, so that MailMan can interface to a machine translation API provided by SYSTRAN, such that inbound emails would get translated into the default language chosen by the user individually from the MailMan options page. They would receive as the default output in the body of the email the translated text, with the original text as an attachment. Any attached files would be left untouched but passed through as defined by regular mailman settings. Of course this would be a paying engagement. -- Regards, Nick Ashton-Hart Director, At-Large ICANN PO Box 32160 London N4 2XY United Kingdom Main Tel: +44 (20) 8800-1011] USA Tel: +1 (202) 657-5460 Fax: +44 (20) 7681-3135 mobile: +44 (7774) 932798 email: nick.ashton-hart(a)icann.org Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / Skype: nashtonhart Online Bio: https://www.linkedin.com/in/ashtonhart

2 1

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 21 May '07

21 May '07

Thanks again for your helpful reply. In particular, I really like the sound of being able to use different databases for different types/sources of data; this sort of ability to integrate is exactly the sort of thing I am envisioning. Re: integrating PHP and Python: I did, after various search combinations, find this presentation from 2002: http://www.csh.rit.edu/~jon/pres/php-2002/pip-applications.ppt, and consequently http://www.csh.rit.edu/~jon/projects/pip/. However, nothing seems to have happened on this since 2002 and so I'm not really keen on it. In any case, thinking about it more I realise that since I want to be able to use a standalone (and possibly remote) Mailman server a PHP/Python combination probably wouldn't be perfect. One thing I did pickup from the presentation above was his use of the Python Mailman modules in his wrapper scripts. I've been looking more into what I can do using those, rather than the command line. At the same time, I've been looking into what can be done (and how easily) using Web Services. In particular, I like the sound of the Zolera SOAP Infrastructure, which seems to provide a very simple way to access Python functions over SOAP. So, my thinking at the moment is to hack up a single Python object which wraps the relevant Mailman modules for the functionality I need to use, then use ZSI to expose that object as a web service. If I need to, I can always just call the command line scripts from that object, so I wouldn't be cutting off any options. This seems to me, at the moment, to be the best compromise between doing it 'properly' and my need to have something up and running quickly, however ramshackle. Benjamin ----- Original Message ---- From: Barry Warsaw <barry(a)python.org> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: mailman-developers(a)python.org Sent: Saturday, 19 May, 2007 12:58:30 AM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 17, 2007, at 8:39 AM, Ben Sims wrote: > With regards to Mailman 3, from my reading I understand that this > will implement SQL-type storage for all configuration and list > data. This would completely take care of my needs in this case I > think; would you perhaps be able to give us a rough idea of progress? Things are moving along well. My work these days has been to complete the data model using Elixir and SQLAlchemy. I had a breakthrough with Elixir a few days ago, so now I'm just working on completing the model, related interfaces, and doctests. My plan is to have a working database backend asap so I can unbreak all the higher level stuff that depends on the data model. Right now I'm working in a branch, but I am going to very soon merge this back to the trunk, even though it will break the trunk. I speak more about this in some later postings. I'm trying to be very diligent about writing interfaces to describe how Mailman interacts with the data model, so you could potentially back it with different storage mechanisms. The idea is that you might want to put your list data in Mailman's default SQLite database, but you might want to get your user data out of your enterprise database. By writing your own implementations of Mailman's interfaces, you should be able to do that. > As a garden-variety PHP developer and Mailman rookie, I doubt how > far I am capable of going deep into Mailman itself to implement a > solution for this. I would be happy to do the research before > dismissing the idea though, if you could point me in the direction > of some bedtime reading on the subject. Given the time I have > available and the limited functionality required, I'm very much > leaning towards the cheapest hack option - which seems likely to be > simply executing command line commands. I wonder if there isn't a cleaner way to integrate PHP and Python. Does anybody know? Or is some form of IPC really the only way to go? Writing command line interfaces to provide the functionality you want should not be difficult at all, if you are comfortable writing Python. > Regarding your questions: > > -- What functionality do you want to expose? > > Not much. To start with, creating and removing lists and adding and > deleting subscribers would probably be enough. Creating and removing lists are a bit hackish now because the logic to do so is spread out in a couple of places. However see the bin/ newlist script or Mailman/Cgi/newlist.py module for examples. The former may already do what you need here. This will get much easier in MM3. Likewise for adding and deleting subscribers. > -- How would you handle security? > > To be honest, I hadn't even got as far as thinking about that, > since I'm not really clear on the mechanisms involved. > > - - Will you have to re-implement much of the CGI logic? > > Again, I haven't gone through closely enough to give a decent > answer. If I was hacking something up which did use the Web > Interface as a gateway, I would be more likely to use Mechanize to > fake a browser and do the intereacting. Ugly I know, but I'm > familiar with that so I could get it to work. Probably much easier to use the existing command line scripts, augmenting or writing your own as needed. Remember you can also do a lot with bin/withlist scripts. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRk4hh3EjvBPtnXfVAQIQ+AP9HupG3WJ9X8hD+vsowrLCq5FwWlw194P9 iB2qHhTbafFlURf/7dXt+JLfX7UjTchydsBPaNR00UwBUZcMohTXCbJJSEi+kMwg 7p32bknigvmC/3qujLzkZz08lwUo86mK6e7q/w55O6fb1DAXVfYiw+1LpBJagZ7h E/iTlLiJHOI= =yIkR -----END PGP SIGNATURE----- ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

2 1

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 21 May '07

21 May '07

Many thanks for your speedy response, Apologies for any ignorance displayed regarding Mailman - I have begun experimenting with it only recently as a way to add mailing list functionality to the existing PHP application I mentioned. (As a side note, a big thank you to whoever builds the Debian package - completely painless, especially compared with Sympa...) With regards to Mailman 3, from my reading I understand that this will implement SQL-type storage for all configuration and list data. This would completely take care of my needs in this case I think; would you perhaps be able to give us a rough idea of progress? As a garden-variety PHP developer and Mailman rookie, I doubt how far I am capable of going deep into Mailman itself to implement a solution for this. I would be happy to do the research before dismissing the idea though, if you could point me in the direction of some bedtime reading on the subject. Given the time I have available and the limited functionality required, I'm very much leaning towards the cheapest hack option - which seems likely to be simply executing command line commands. Regarding your questions: -- What functionality do you want to expose? Not much. To start with, creating and removing lists and adding and deleting subscribers would probably be enough. -- How would you handle security? To be honest, I hadn't even got as far as thinking about that, since I'm not really clear on the mechanisms involved. - - Will you have to re-implement much of the CGI logic? Again, I haven't gone through closely enough to give a decent answer. If I was hacking something up which did use the Web Interface as a gateway, I would be more likely to use Mechanize to fake a browser and do the intereacting. Ugly I know, but I'm familiar with that so I could get it to work. Sorry that I don't have the experience to come up with better ideas on this; as I said, I welcome input from anybody that has already attempted this kind of work. Regards, Benjamin ----- Original Message ---- From: Barry Warsaw <barry(a)python.org> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: mailman-developers(a)python.org Sent: Wednesday, 16 May, 2007 4:05:53 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 16, 2007, at 5:00 AM, Ben Sims wrote: > All > of these are rather clunky. My dream response would be some sort of > Web > service / API interface with a corresponding PHP client object, but I > haven't been able to find any evidence of this existing. I think this could be handled fairly easily, and it would make an excellent project for Mailman 3. You could prototype the work for Mailman 2.1 fairly easily too. The way I'd go about thinking about this would be to implement a qrunner based on Python's standard SimpleXMLRPCServer module. While not technically a 'queue runner', we already have some precedence in the trunk for running other types of long-running processes from the qrunner architecture, so while a slight misnomer, it's quite workable. The questions of course are - - What functionality do you want to expose? - - How will you handle security? - - Will you have to re-implement much of the CGI logic? I think you could pretty easily throw together the architecture for this and then start to answer the other questions. In Mailman 3 I'm trying hard to get functionality that lives only in the CGI or command line scripts accessible through the standard Mailman package. One other thing to think about: In the trunk, we already have a wsgi- based web server which should allow sites to swap in their own HTTP- based access to Mailman if they wanted (e.g. via Zope, Django, TurboGears, etc.). Many of these web publishing frameworks also have XMLRPC publishing. I don't know what the standards there are, but IWBNI we could swap those publishing mechanisms as well. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRksBsnEjvBPtnXfVAQKOqgP9HzgbldPeM8QNEsbN98PbksHVzP/qBOEN isXu3dDHGvtTx8DxJbgtQ2R0qSPJU7nsKvIC8O1Iqw01t+89MZLVEbCAx+uiPj1K wPXsYoitDW4XeN7CCfBE+xoEFL++mRqH6K3MC3zOavqt6HZ07hbQBKLE/XmMEepR BAcTbwnUEjI= =nwzh -----END PGP SIGNATURE----- ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

3 2

Interacting with mailman remotely through APIs / wrappers
by Ben Sims 16 May '07

16 May '07

Hello to all, I'm currently looking into ways to interface with Mailman remotely. Specifically, I want to use a PHP based application on a different server to create and delete lists and add and remove subscribers. There have been discussions touching on this on this list in the past (for example http://mail.python.org/pipermail/mailman-developers/2005-November/018299.ht…, and http://mail.python.org/pipermail/mailman-developers/2001-April/008549.html seven years ago). As far as I can see though, nothing ever came of these in terms of stable, released products. Does anybody here have any information or ideas as to the best way to achieve this sort of thing? At the moment, I am looking at: - faking POST requests to the web interface - writing files for consumption by config_file and then sending them over - sending requests by email to the list - writing shell files to be transferred to the target server and executed All of these are rather clunky. My dream response would be some sort of Web service / API interface with a corresponding PHP client object, but I haven't been able to find any evidence of this existing. Thanks for any tips, Benjamin ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

3 2

Styling patch
by A.M. Kuchling 14 May '07

14 May '07

Patch #1415956 from Bryan Carbonnell adds CSS for styling purposes and changes the HTML to be valid XHTML1.0. It still needs some tidying up, and it still uses tables for layout, but that patch takes us halfway there. It presents one big compatibility issue that will probably need to be fixed. The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with CSS class declarations. It's probably unacceptable to break the use of these settings, so there needs to be some compatibility fix. Colours could be substituted into the .css file somehow, or a 'style' attribute could be added as well as a 'class' attribute. Does anyone have suggestions for what to do? Patch URL: <http://sourceforge.net/tracker/index.php?func=detail&aid=1415956&group_id=1…> [Aside: are there many patches in the tracker that could be useful? I don't know how actively they've been getting processed. Does there need to be a push to process bugs and patches?] --amk

10 20

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8215]branches/exp-elixir-branch/Mailman/Handlers/ Scrubber.py
by Mark Sapiro 11 May '07

11 May '07

bwarsaw(a)users.sourceforge.net wrote: >Log Message: >----------- >Forward port more of Mark's r8204 fixes: > >- Handlers/Scrubber.py > Fixed a scrubber issue where the i18n translated 'next part' separator > can be garbled if the list charset is different from the message. > >Note that the other parts of the Scrubber.py and Decorate.py changes in r8204 >have already been applied to the trunk. > >Modified Paths: >-------------- > branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py > >Modified: branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py >=================================================================== >--- branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py 2007-05-10 03:08:48 UTC (rev 8214) >+++ branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py 2007-05-10 03:59:31 UTC (rev 8215) <snip> >@@ -331,6 +343,13 @@ > charsets.append(partcharset) > # Now join the text and set the payload > sep = _('-------------- next part --------------\n') >+ # The i18n separator is in the list's charset. Coerce it to the >+ # message charset. >+ try: >+ s = unicode(sep, lcset, 'replace') >+ sep = s.encode(charset, 'replace') >+ except (UnicodeError, LookupError, ValueError): >+ pass > rept = sep.join(text) > # Replace entire message with text and scrubbed notice. > # Try with message charsets and utf-8 I'm not sure the above patch is necessary (or even correct) in the trunk. I looked at Tokio's port of my Scrubber.py changes to the trunk. and it looked to me that Tokio had accounted for this issue in a different way. BTW, I haven't looked at all of Barry's port of my recent patches, but I also ported them to my working copy of the trunk. I didn't commit them because although I'm sure they were ported correctly, I wanted to run a few tests first. Unfortunately, I updated my working copy from the trunk before starting and then found that the trunk's current state was not usable for me :-( -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Should we move to Bazaar?
by Barry Warsaw 10 May '07

10 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very encouraged and excited by all the interest from developers who want to get involved in the Mailman project. I've always wanted to broaden the sphere of developers beyond the current core three (though I can't say enough about the great job Tokio and Mark do). I think this is a good time to ask whether we should move from Subversion to Bazaar <http://www.bazaar-vcs.org> for our source code revision control system. There are plusses and minuses, and I will not make the decision unilaterally (unless you want me to. :). Certainly, Tokio's and Mark's opinions are very important here because they are currently doing exceptional work on the 2.1 branch and I don't want to jeopardize that! Let me outline my thinking here and get your feedback. Bazaar is a distributed version control system. This is really the crucial different between centralized systems such as Subversion and CVS, and it's the main draw for wanting to switch. Using a dvcs such as Bazaar really changes the way we as developers work on the code, and the way other non-privileged developers can interact with the project. The biggest differences are that you can work completely disconnected from the central server, and you need have no special permissions to have *and publish* fully revision controlled personal branches. The cons are that it's not as mature as Subversion or CVS, but I have confidence that it's pretty stable. It has not yet reached a 1.0 release, but I think that's coming soon. (It's been ported to *nix, OS X, and Windows, and it's written in Python if that matters). It does not have all the features of Subversion (e.g. nested branches or externals), but it has enough to make it useable for everyday development. It takes some getting used to for existing Subversion and CVS users, and the documentation is not as good. But I think people can pick it up fairly quickly and there's a lot of effort being put into it. Full disclosure: my company Canonical is the driving force behind Bazaar, and uses it internally for all our development. It's free software though, so no worries on that front. I would not recommend it for the Mailman project though unless I thought it could solve some real problems, that it was stable enough to rely on, and that Mailman would benefit from using it. Having insiders to heckle helps, but it wouldn't be enough if that's all there was. What problems does it solve? Well, I'm /still/ struggling to merge in the work I did while on the train to PyCon in Dallas because of all the contortions I had to go through to work off-line for a couple of days. Bazaar solves this by allowing me to do everything I need to do while completely disconnected, except push my changes to the master branch. I could have committed, branched, merged, reverted, etc. all in a completely revision controlled way while off-line, and then I could have merged all my changes back to the master branch when I got back on-line. It also solves a problem I have of many live branches. Branches in Bazaar are cheap, unlike in Subversion. This means I can easily create branches for my Elixir experiments, for the move to eggs, for playing with 5 different templating engines, etc. And it's easy to merge between these. I can also have private branches that need never see the embarrassing light of day until they are stable enough to merge into the main line. What problems does it solve for you? Well, if you're a developer wanting to contribute to Mailman but we don't know you well enough to give you commit privileges, you almost don't care. You can branch from the main branch, and have a fully revision controlled private branch at your disposal. You can do commits, branches, merges, etc. on your local branches. You can even publish them via http, bzr+ssh, or sftp. Why is that cool? Well, say you created the best damn templating patch EVAR and you wanted everyone to see it. Just publish your branch (or create a bundle -- a mailable tarball-like unit of your changes) and pass around the URL. Anyone can then take a look at your branch, and the core developers can merge them into the mainline if we like them. It's a great way for new developers to earn some street cred with minimal admin overhead. And if we /don't/ like your changes, you do not have to maintain them as a disembodied patch. You can say "screw the Mailman guys, here's my cool fork" and have a fully revision controlled version of your own, in a way that's much easier to track with upstream than with Subversion or CVS. One more thing. If we move to Bazaar, I would host the branches on Launchpad.net, which -- full disclosure again -- is developed, managed, and paid for by my employer. Why Launchpad? Because it's convenient, I have insiders I can bug, and because it already supports hosted Bazaar branches. Let me emphasis that Canonical is in no way driving this. They don't care what we do for Mailman, and understand fully that stuff like this are community decisions. I personally think Bazaar+Launchpad will make some of our lives easier, but if you guys do not agree, we'll stick with what we've got, no harm, no foul. Please do share your opinions freely here in public, or via private email. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjkMDHEjvBPtnXfVAQLcXgP/fnriiMwu9gAQEvXmUiGLXLSfkcmkzyAm cqbu2QjmTm7uZapFq3WLmItfBuoVP3HkOdaa+ibpgR8WJUxt6UksbFXCSPPxmWlR tPI8BS65r0gnf0MUM3dvbvkhizGVmYkhK7gAW6dmH43Um1o5CbskkbaWjIMLJ+0L ter/gGwLu+8= =ftG9 -----END PGP SIGNATURE-----

14 48

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8210] branches/modernize_21_webui/mailman/devel/ run-server.py
by Barry Warsaw 08 May '07

08 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2007, at 3:06 PM, akuchling(a)users.sourceforge.net wrote: > Revision: 8210 > http://svn.sourceforge.net/mailman/?rev=8210&view=rev > Author: akuchling > Date: 2007-05-08 12:06:28 -0700 (Tue, 08 May 2007) > > Log Message: > ----------- > Add a little web server script Cute! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkDM13EjvBPtnXfVAQLDSAP8DS8qQLT9dVw+YaF1puC40o5Q8rM5a1AD sVFwADCT0VIc9C+SABjre38Lu7ZdKphILDUgCLMEusBJrbEuH7slpFJsVOQp0CQK Z/E8/Xu362wOaExgSqEMGH60rroFCadP7CDYKORCUNMLQ2Z8BNq33LsIPRnvR2L6 1hVApHgw+gU= =wvPM -----END PGP SIGNATURE-----

1 0

Templating the interface
by Aaron Crosman 05 May '07

05 May '07

Since Barry suggested that conversation about improving the mailman GUI should be moved here, I thought I'd take a minute to ask a couple starter questions. First, let me say, that I'm willing to do some of the work on this part of the project. In the organization I work for (and run mailman for) the biggest complaints I hear revolve around the interface, and the lack of control over the design, so I'd love to see a proper template system in place. That said, I'm not clear where this project stands. I've been reviewed the summary from last summer's SoC work, and while that's given me some idea of what was done, I don't have a good sense of how and where to get started on helping. Can you all offer some suggestions about what I can do to be helpful and contribute? Aaron

12 24

status of backscatter prevention?
by Jo Rhett 04 May '07

04 May '07

I remember a number of threads about backscatter prevention, but I don't remember the result. Perusing the archives isn't much more enlightening. Where are we on this? In particular, other than removing all but one of the aliases, have we made it easier for people to run a backscatter proof list? Meaning that all subscribe, unsubscribe, etc are done on the web ui and nothing in the server automatically responds to e-mail other than legitimate list mail sent by subscribers? I also remember discussions about honoring SpamAssassin headers to detect spam. Status of this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

1 0

Developing for mailman is hard
by Ethan Fremen 04 May '07

04 May '07

Hi! I'm a spoiled young brat who used to have ambitions to be a graphic designer, did a couple of underground 'zines right around when this whole "web" thing started. Anyway, so I got dragged kicking and screaming into the programming side of things- astute googling would find some posts of me complaining that there's no good GUI for Apache. What drew me to mailman back in the mid 90's was the fact that it had a nice web interface, so I have always thought of mailman as a web app that happens to handle message processing. Client side web development is really kind of dreamy; you edit the file, upload it to the server, see what's changed, lather rinse repeat. PHP doesn't stray far from this model; most PHP "apps" are "drop this folder into your DOCHOME and give it DB privs" to set up. Usually, developing for these apps can be done right from a checkout, or at the very least once the build process is complete there aren't any dependencies on it. I can find no way to get anywhere close to this model in trying to improve the web UI. To be clear, my ignorance of make, ant, and all that is pretty much nonexistent, so I'm hoping my most crucial problems are merely on account of that ignorance. * running instance -> checkout issues. I want to make changes to mailman python objects and get those changes back into a checkin. The closest I came to a working approach was: 1.) build mailman. 2.) fiddle settings so that the web UI doesn't interfere with other mailman install. 3.) remove the Mailman directory and symlink the Mailman directory from the repository. This more or less works, but any time I want to add, rename or delete anything I have to fix all the makefile stuff in order for the branch to be buildable. I also can't re-run the build process without repeating the delete/symlink dance. (also, the HTTPserver has to be restarted on each change... i vaguely fixed that on my branch, but I have no idea if that made it in elsewhere). This will partially be mitigated if we move to a distributed source code model, because I can just maintain all the utterly gerfucked branches I need to and I won't be cluttering other people's revision logs with all sorts of SVN modifications. How do you "round trip" between a test instance and source code? * Templates bult on compile. I want to make changes to the templates and then make sure they build properly in all languages, I have the right i18n strings, etc. The UI templates seem to be built during compile time; while there is vast consensus that pre-building templates should change, is there any way to just rebuild templates from the command line? There are a bunch of other itches I have, but this is the one that makes scratching most difficult for me at the moment. Thanks for listening ;) ~ethan

1 0

Starting a CSS wiki page
by A.M. Kuchling 03 May '07

03 May '07

I've started a page with random notes about adding CSS: http://wiki.list.org/display/DEV/StyledPages Edit away! Given my interest in the archiver, I'm starting by looking at the archive templates and noting some ideas for what should be added. --amk

1 0