Re: [Mailman-Developers] Searchable archives for MM
Args, I knew I forgot sth, I should have selected MIME digest :) On Thu, Aug 06, 2009 at 22:19:30 -0700, Jordan Hayes wrote: Here's my solution: http://infothecary.org/jordan/mailman.html Nice solution Jordan, but I think about a pythonic way to fully integrate searchable archives into MM. I was using the debian archive search only as an example for what can be achieved on big archives. Thanks Siggy -- bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] mailman user password
Sorry Adam for hijacking, I'm not subscribed to mm-users. On Fri, Aug 07, 2009 at 15:46 +0100, Adam McGreggor wrote: *shimmied over to mailman-devs* (from -users) On Fri, Aug 07, 2009 at 10:33:06AM -0400, Barry Warsaw wrote: It kind of sucks that there are so many other Mailman command line scripts, which is one reason why I've always put them in a separate Mailman specific bin directory. With MM3 though I intend to use a 'subcommand' approach so that there's only one 'mailman' command. Think things like 'mailman listmembers foo'. I'll probably keep mailmanctl separate though I haven't decided about that yet. I applaud you on this, Barry. I seem to remember discussions where to place these commands for Debian, ATM they pollute the /usr/sbin namespace. May I suggest to put mailman in /usr/bin while mailmanctl stays in /usr/sbin. Would it too much to ask for the 'old' (read 'current') scripts/commands to be aliased: at least in the first few releases? e.g., for 'list_members' to link to 'mailman listmembers' Perhaps as an install/configure/compilation option? Create old-style links? --old-style-links You might contribute some shell scripts simulating old behavior, a Debian package would then ask an additional debconf question whether to install these compatibility scripts or not. Regards Siggy -- bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Attachment icon in archives
For me, having a paperclip or some other indication of an attached file on messages in the archive would go a long way towards helping me find the message I am looking for. Has anyone else thought this and found or know of a solution? Cheers, Justin ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Searchable archives for MM
On Fri, Aug 07, 2009 at 13:40 -0700, Mark Sapiro wrote: Siggy Brentrup wrote: In contrast to his suggestions (sth involving google search) I'm aiming at a solution akin to Debian's Xapian powered ML search. cf http://lists.debian.org/cgi-bin/search What do you think and is anybody else interested in working on this? There are patches at http://www.openinfo.co.uk/mm/index.html that integrate the ht://Dig search engine with Mailman's archives. They work well. The problem with integrating these or some of the other solutions into the source is they require installation of software over which we have no control. From a Debian point of view this isn't much of a problem, I might create a patched mailman-searchable-archives package that depends on htdig, eventually factoring out common parts to yield: mailman mailman-searchable-archives \ /\ mailman-common htdig but it doesn't address concerns about pipermail. MM 3 seems to me to be an opportunity to address all these issues, we might learn from ht://Dig or Xapian (both written in perl and C iirc) to implement an enhanced pipermail. These are only first thoughts, before deciding which way to go a lot of research is still necessary and I'm open to any suggestions. Regards Siggy -- bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Getting code in? (was: Storm based MemberAdaptor for Mailman)
On Sat, Aug 8, 2009 at 1:25 AM, Malveeka Tewarimalve...@gmail.com wrote: I am working on writing a storm based member adaptor for mailman so that the mailman membership data can be stored in a database instead of .pck files. The reason for choosing storm is that it provides an abstraction to use any underlying db language- either mysql, postgresql or sqllite. Hi, I'm one of the GSOC mentors for Systers, all of whose students are working on Mailman enhancements. Some of these (Like Malveeka's) would be suitable for merging upstream, but the review and acceptance process is not clear. * Do people on this list regularly provide review of proposed enhancement patches? * Is there a set of people who explicitly ACK or NAK all proposed patches? * Once reviewed, merging is via LP merge requests, right? Or does one do the merge request and *then* get reviewed? * More fundamentally, is Mailman currently accepting patches from external contributors? We have code to contribute. It's not perfect yet but we will make it better. We need some Official Mailman participation or our improvements will never make it out of our branch. Even a response of we're not interested in X, thanks would be much superior to no response at all. Thanks -- Regards -- Andy ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Searchable archives for MM
Siggy writes: Here's my solution: http://infothecary.org/jordan/mailman.html Nice solution Jordan, but I think about a pythonic way to fully integrate searchable archives into MM. Um, you need Phython in this equation exactly why? The archives are web pages. Who cares what language was used to implement the search? You don't demand a Python web server to deliver your archives, do you? I was using the debian archive search only as an example for what can be achieved on big archives. For me, I think the people who Think Hard about searching text can work in whatever language they want; SWISH-E has done a good job of providing a platform for search, and it's easily integrated with Mailman. FWIW, I have lots of big archives ... /jordan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Searchable archives for MM
Nice solution Jordan, but I think about a pythonic way to fully integrate searchable archives into MM. If you are interested in PyLucene, I would be very happy to share maintenance of the relevant Debian package. -Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] mailman user password
On Aug 7, 2009, at 11:26 AM, Bernd 'Siggy' Brentrup wrote: I applaud you on this, Barry. I seem to remember discussions where to place these commands for Debian, ATM they pollute the /usr/sbin namespace. May I suggest to put mailman in /usr/bin while mailmanctl stays in /usr/sbin. I'm not yet sure how the buildout based source build will translate into installation recipes, but I generally concur with this. I'm nearly certain that mailmanctl's functionality will not appear in the 'mailman' command (which I already have working and committed to the trunk!). We'll have to figure that out when the release is closer. -Barry PGP.sig Description: This is a digitally signed message part ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Getting code in? (was: Storm based MemberAdaptor for Mailman)
On Aug 9, 2009, at 3:35 PM, Andrew Grover wrote: Hi, I'm one of the GSOC mentors for Systers, all of whose students are working on Mailman enhancements. Some of these (Like Malveeka's) would be suitable for merging upstream, but the review and acceptance process is not clear. Very cool to hear about your work! Let's see if I can clarify things. Eventually this ought to make it into the wiki. * Do people on this list regularly provide review of proposed enhancement patches? * Is there a set of people who explicitly ACK or NAK all proposed patches? * Once reviewed, merging is via LP merge requests, right? Or does one do the merge request and *then* get reviewed? I think the process should generally work like this: * A developer has an idea for an enhancement. They describe it here and we can discuss general design issues, coding suggestions, decomposition of work into branches, etc. For higher bandwidth discussions we can use irc. * If the idea or approach isn't something the Mailman community thinks is worthwhile, we'll leave official participation at that. Of course, this being open source and bzr being a DVCS, you're free to do whatever you want. * If the idea is appropriate for Mailman, we must get copyright assignments from the developer. Let's do this early, since it can take some time to get all the paperwork to the FSF. * Branches should be as small as possible and still be self- contained. They must include documentation, a NEWS entry, and for Mailman 3 they must include tests. Ideally, there would be one bug for every branch you work on. The smaller the branch the easier it is to review. For Launchpad, we have a strict 800 line diff limit on branches. I'm not sure if that's appropriate or not for Mailman, but please understand that anything over 1000 lines of diff gets very difficult and time consuming to review. * When a branch is ready for review, create a merge proposal for it and email us here. * One of us will review the code. For Mailman 2.x, it will most likely be Mark. For Mailman 3 it will be me. * Once we've approved the branch, either Mark or I will merge it into the official trunks. Currently only a few of us have write permission to the official branches. I do hope more people become developers and reviewers! * More fundamentally, is Mailman currently accepting patches from external contributors? Yes. It's tough though, and I apologize in advance, but both Mark and I are very busy. I've tried to shed load by concentrating only on Mailman 3 and that seems to work for me (and hopefully MM3, which is making good progress). We have code to contribute. It's not perfect yet but we will make it better. We need some Official Mailman participation or our improvements will never make it out of our branch. Even a response of we're not interested in X, thanks would be much superior to no response at all. Completely agreed! Let's talk about your ideas and see which might be appropriate for inclusion. I will really work at being more responsive. -Barry PGP.sig Description: This is a digitally signed message part ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Storm based MemberAdaptor for Mailman
On Aug 8, 2009, at 4:25 AM, Malveeka Tewari wrote: I am working on writing a storm based member adaptor for mailman so that the mailman membership data can be stored in a database instead of .pck files. The reason for choosing storm is that it provides an abstraction to use any underlying db language- either mysql, postgresql or sqllite. I'm a big fan of Storm. It's the ORM used in Mailman 3 and I've had a lot of good success with it. Please note that this new member adapter cannot go officially into Mailman 2.1, but I do think it might be useful for Mailman 2.2, probably as unofficial contrib, though Mark may want to weigh in on that. Because the schema is so different in Mailman 3 and we already use Storm, this won't be relevant for that branch. The ideal case would be to use only a database and no pickle files for Memberships data but I have not reached there. I had tried to read and use the data from the database instead of pickle files and that had broken my Mailman which leaves me with few questions Are you using Pickle() fields for non-scalar data types? (i.e. lists and dictionaries). Of course, you don't gain from relational data that way, but it's still useful. In OldStyleMemberships.py the lower cased email address is used as a key for accessing the membership properties. However in my schema, I am using the (listname, case preserved email address) as the PK. Is it possible that not storing and using LCE as a key might break something. From OldStyleMembership's (very loose) contract, I think the answer is yes. It doesn't matter so much how you store things in the database, but you will have to honor the contract that the MemberAdapter.py promises. I also want to make sure that in the database I am caturing all the Memberships data. Presently my database uses the following class as a storm abstraction for the database. Do I need to add/remove anything? class PgsqlMembers(object): __storm_table__ = mailman_test __storm_primary__ = listname,address listname = Unicode() address = Unicode() password = Unicode() lang = Unicode() name = Unicode() digest = Unicode() delivery_status = Int() user_options = Int() topics_userinterest = Unicode() bounce_info = Unicode() delivery_status_timestamp = Unicode() When I was creating the schemas for MM3, I basically had to inspect OldStyleMembership.py to see what fields it requires, then fix things as tests broke. MM2 has the great disadvantage that there isn't a usable test suite. This is fixed in MM3. So I think you're left to manual testing until it basically works for you. :( -Barry PGP.sig Description: This is a digitally signed message part ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Searchable archives for MM
On Aug 9, 2009, at 9:31 PM, Jordan Hayes wrote: Um, you need Phython in this equation exactly why? The archives are web pages. Who cares what language was used to implement the search? You don't demand a Python web server to deliver your archives, do you? Heh, well Mailman 3 will include a couple of Python web servers. There will definitely be a web server for the REST interface and the web ui will likely be vended from a Python web server. They're super easy to write! Note that we've adopted WSGI for all web protocols so the ultimate port 80 listener can be almost anything. This will make it easy to integrate with frameworks such as Zope, Django, Turbogears, etc. or even Apache through mod_wsgi. I'm going to need really strong arguments to bundle anything not written in Python. I was using the debian archive search only as an example for what can be achieved on big archives. For me, I think the people who Think Hard about searching text can work in whatever language they want; SWISH-E has done a good job of providing a platform for search, and it's easily integrated with Mailman. FWIW, I have lots of big archives ... The way to think about this then is modularization and pluggability. The archiver itself is already pluggable (with more well defined interfaces in Mailman 3). The question is whether for Pipermail, the search itself should be pluggable. Think about how that would work. -Barry PGP.sig Description: This is a digitally signed message part ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
