From f at state-of-mind.de Mon Nov 5 21:18:23 2012 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 05 Nov 2012 21:18:23 +0100 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman In-Reply-To: <20121026141524.7f775bd8@resist> References: <50878A5D.7070807@zone12.com> <508A2DC3.2070503@sys4.de> <20121026141524.7f775bd8@resist> Message-ID: <50981F0F.4000301@state-of-mind.de> Hi, On 10/26/2012 08:15 PM, Barry Warsaw wrote: > One thing we need though is an authenticating proxy for the REST API so that > non-localhost users can script their own changes to lists they own or are > members of. We can't expose the admin REST API to non-localhost and I really > don't want to have to add the authentication layer to the default REST API (at > least not right now). > > It's possible that such an authenticating layer could be implemented as part > of Postorius, since I think Django supports REST also, and you'll *have* to be > authenticated to interact with Postorius. OTOH, it would be nice if that > could be provided without requiring Django. Of course it would be nice if a public API wouldn't require Django. But we already have authorization functionality for all kinds of roles in Postorius. And to add a JSON API shouldn't be so hard. In fact, I played around with this a little over the weekend. I didn't want to change too much of the existing authorization system, only slightly enhance it to provide a simple way for non-browser clients to log into Postorius with existing user credentials. What I came up with is a simple view decorator that checks for an HTTP Basic Auth header if the current user isn't logged in and uses these credentials to start a new Django session. Clients that can handle session cookies can use that in all concurrent requests (which makes it a little faster). Clients that don't support cookies can just send the auth header again with the next call. Theres also an API resource that returns a json string with all mailing lists (very similar, but not identical to the one the core API returns). If anyone's interested: I added a small proof of concept for a command line client to a private branch on launchpad. It's far from mature, just to see if the idea works... https://code.launchpad.net/~flo-fuchs/+junk/mmremote. (Please make sure to use the latest revision of Postorius). Another thought: We will add some convenience AJAX functionality to the Postorius UI. For this alone it's worth having a number of JSON resources available. In other words: Postorius would be the first client to use its own API :-) Cheers Florian > > Cheers, > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/f%40state-of-mind.de > > Security Policy: http://wiki.list.org/x/QIA9 > From p at sys4.de Tue Nov 6 22:59:09 2012 From: p at sys4.de (Patrick Ben Koetter) Date: Tue, 6 Nov 2012 22:59:09 +0100 Subject: [Mailman-Developers] Mailing Lists and Non-ASCII Addresses Message-ID: <20121106215909.GD3522@sys4.de> Just published a few minutes ago: Probably worth to read before pushing MM3 out. p at rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich From barry at list.org Wed Nov 7 22:48:02 2012 From: barry at list.org (Barry Warsaw) Date: Wed, 7 Nov 2012 16:48:02 -0500 Subject: [Mailman-Developers] Mailing Lists and Non-ASCII Addresses In-Reply-To: <20121106215909.GD3522@sys4.de> References: <20121106215909.GD3522@sys4.de> Message-ID: <20121107164802.6f881ab2@resist.wooz.org> On Nov 06, 2012, at 10:59 PM, Patrick Ben Koetter wrote: >Just published a few minutes ago: > > > >Probably worth to read before pushing MM3 out. https://bugs.launchpad.net/mailman/+bug/1076152 Cheers, -Barry From barry at list.org Wed Nov 7 22:58:46 2012 From: barry at list.org (Barry Warsaw) Date: Wed, 7 Nov 2012 16:58:46 -0500 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman In-Reply-To: <50981F0F.4000301@state-of-mind.de> References: <50878A5D.7070807@zone12.com> <508A2DC3.2070503@sys4.de> <20121026141524.7f775bd8@resist> <50981F0F.4000301@state-of-mind.de> Message-ID: <20121107165846.727c7364@resist.wooz.org> On Nov 05, 2012, at 09:18 PM, Florian Fuchs wrote: >Of course it would be nice if a public API wouldn't require Django. But we >already have authorization functionality for all kinds of roles in >Postorius. And to add a JSON API shouldn't be so hard. I think it's great for Postorius to provide an authenticated API. The beauty of our approach is that if someone wants to start a separate project for a Django-less authenticated API, there's nothing stopping them. >In fact, I played around with this a little over the weekend. I didn't want >to change too much of the existing authorization system, only slightly >enhance it to provide a simple way for non-browser clients to log into >Postorius with existing user credentials. What I came up with is a simple >view decorator that checks for an HTTP Basic Auth header if the current user >isn't logged in and uses these credentials to start a new Django >session. Clients that can handle session cookies can use that in all >concurrent requests (which makes it a little faster). Clients that don't >support cookies can just send the auth header again with the next call. Does Django support OAuth? If so, I think that will be better in the long run than Basic AUTH, though I think both must be used over HTTPS for security reasons. I had some very interesting discussions with one of the original OAuth authors at UDS-R, and while v1 has its issues, v2 seems to be even worse. Yet, it seems like the best option out there if users want to use applications without having to provide their login credentials directly. Fortunately, there are several Python libraries that support at least OAuth v1, although the library I'm currently liking is liboauth, which supports both v1 (client) and the draft for v2. As I understand it, only Facebook's API requires v2; most services support v1 and it's not that hard to support on both the client and server. >Theres also an API resource that returns a json string with all mailing lists >(very similar, but not identical to the one the core API returns). > >If anyone's interested: I added a small proof of concept for a command line >client to a private branch on launchpad. It's far from mature, just to see if >the idea >works... https://code.launchpad.net/~flo-fuchs/+junk/mmremote. (Please make >sure to use the latest revision of Postorius). > >Another thought: We will add some convenience AJAX functionality to the >Postorius UI. For this alone it's worth having a number of JSON resources >available. In other words: Postorius would be the first client to use its own >API :-) I *love* eating my own dogfood. :) -Barry From pidgeot18 at gmail.com Thu Nov 8 00:11:05 2012 From: pidgeot18 at gmail.com (Joshua Cranmer) Date: Wed, 07 Nov 2012 17:11:05 -0600 Subject: [Mailman-Developers] Mailing Lists and Non-ASCII Addresses In-Reply-To: <20121106215909.GD3522@sys4.de> References: <20121106215909.GD3522@sys4.de> Message-ID: <509AEA89.8080001@gmail.com> On 11/6/2012 3:59 PM, Patrick Ben Koetter wrote: > Just published a few minutes ago: > > > > Probably worth to read before pushing MM3 out. > > p at rick > > Executive summary: There are basically three orthogonal issues to worry about: 1. Do we accept messages that need SMTPUTF8 transport? 2. Do we accept non-ASCII people as subscribers? 3. Is our address non-ASCII? If we answer "yes" to 1, we need to either require that all of our subscribers support SMTPUTF8 [detection is nontrivial, but user-initiated confirmation can do it] or we need to downgrade messages that we receive for non-SMTPUTF8 clients. It is also important to note that there is no way to properly downgrade an email address that is non-ASCII. Alternatives listed are: * Require subscribers to list an ASCII fallback if a non-ASCII email address is used * Provide an ASCII forwarding address in the list software * Rewrite the From (Sender, etc.) with our address and don't give a proper From If the answer to 3 is "yes", all of the munging of headers (this includes both Reply-To and List-*) may need to be prepared in both non-ASCII and downgraded form, and notes that percent-encoding of email addresses could cause spurious rejection of email addresses as invalid. The second issue deals primarily with needing to construct non-ASCII envelopes for some subscribers, which is necessary anyways if 1 or 3 are both true. In terms of code impact, it probably boils down to the following: 1. What do we do if we receive a non-ASCII mail delivered to a list? 2. How do we find out if subscribers support SMTPUTF8 transport? 3. What are implications for our configuration (server name and list name)? -- Joshua Cranmer News submodule owner DXR coauthor From terri at zone12.com Sun Nov 11 00:54:54 2012 From: terri at zone12.com (Terri Oda) Date: Sat, 10 Nov 2012 16:54:54 -0700 Subject: [Mailman-Developers] Mailman 3: dlist integration Message-ID: <509EE94E.6070303@zone12.com> I suspect the person to answer this is Barry, but I'm sending to the developers list just in case. I'm working through getting dynamic sublists (dlists) integrated into Mailman 3 (probably targeting the 3.1 release) and I've got a question: where should the thread name be stored? Does that go with the message? Does it need to go in a separate table with message+list as keys? Some background: Dynamic sublists is an Mailman 2.1 extension that systers uses so that mailing list subscribers can subscribe or unsubscribe to individual conversations on a mailing list. It's sort of like a fancier, more automated version of topics, where users can start new conversations at will by sending to mailinglist+new at example.com. This is in contrast to topics, which need to be set up by the admin in advance. It's a pretty neat feature and one they've been using for quite a long time, so it's well-tested and because "I wish I could unsubscribe from this stupid thread" is a pretty common requested feature, I'm hoping we can use dynamic sublists to replace topics in Mailman 3. In a dlist-enabled list, every message is part of a thread, as determined by the posting address used (mailinglist+threadname at example.com or +new for a new thread whereupon we create a new name). We need to somehow have the thread name passed around with the message, and I'm *guessing* that just putting that metadata in with message is the right choice, but I'm worried that message doesn't seem to have listinf stored so maybe the message is list-independent and could be sent to multiple lists and thus be on multiple threads at once. (Incidentally, the other stuff we need to store is the user default preference for new threads, which can go in their preferences, and the user/list/thread preference for threads they've specifically subscribed or unsubscribed from, which will have to be a separate table.) So, um, Barry... where would you prefer that I stick the thread metadata? Terri From turnbull at sk.tsukuba.ac.jp Mon Nov 12 02:31:09 2012 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Mon, 12 Nov 2012 10:31:09 +0900 Subject: [Mailman-Developers] Mailman 3: dlist integration In-Reply-To: <509EE94E.6070303@zone12.com> References: <509EE94E.6070303@zone12.com> Message-ID: <87625bhajm.fsf@uwakimon.sk.tsukuba.ac.jp> Terri Oda writes: > In a dlist-enabled list, every message is part of a thread, as > determined by the posting address used > (mailinglist+threadname at example.com or +new for a new thread whereupon > we create a new name). How is the new name determined? What happens if you just post to mailinglist at example.com? Is it possible to split or merge threads? > We need to somehow have the thread name passed around with the > message, and I'm *guessing* that just putting that metadata in with > message is the right choice, but I'm worried that message doesn't > seem to have listinf stored so maybe the message is > list-independent and could be sent to multiple lists and thus be on > multiple threads at once. What happens occasionally on Python lists is that a discussion that originates on one list will propagate to another, then disappear from the first, then come back to the first. (distutils-sig is especially famous for this behavior, with the "other list" being python-dev.) What behavior would you propose for the dlists in this case? From terri at zone12.com Mon Nov 12 08:01:26 2012 From: terri at zone12.com (Terri Oda) Date: Mon, 12 Nov 2012 00:01:26 -0700 Subject: [Mailman-Developers] Mailman 3: dlist integration In-Reply-To: <87625bhajm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <509EE94E.6070303@zone12.com> <87625bhajm.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <50A09EC6.5090704@zone12.com> On 12-11-11 6:31 PM, Stephen J. Turnbull wrote: > How is the new name determined? With Systers' current setup, I believe it takes the largest word in the title (skipping obvious stop words) and adds a 3 digit number if necessary. There might be some truncation if the word is super long and some de-duplication code -- I don't recall the full algorithm. > What happens if you just post to mailinglist at example.com? Right now, it sends you a message saying that you need to either post to +new to start a new thread or reply to an existing thread, with some appropriate help text. > Is it possible to split or merge threads? Posters can split off a thread at any time by just replying to +new instead of the existing thread. There is currently no way to merge threads. > What happens occasionally on Python lists is that a discussion that > originates on one list will propagate to another, then disappear from > the first, then come back to the first. (distutils-sig is especially > famous for this behavior, with the "other list" being python-dev.) > > What behavior would you propose for the dlists in this case? > What it currently does is nothing in particular -- if you add the posting address with the old dlist name in, it would post back to that dlist. If you put in a +new, it would make a new one. If you did no specifying of the dynamic sublist/thread manually, it'll tell you to choose one. I can't think of a better way to handle this off the top of my head for much the same reasons that correctly threading archives is hard. If we're seriously going to have this replace topics, we might want to make it so something like the existing topic indicators could be tied to a thread somehow too ("topic: dlistthread" headers as an option instead of +dlistthread?) but for a first pass, I just want to do as much of a straight port of the existing code as I can. It's been well user-tested in that state (the systers list being the largest example, with over 3k users and has been running for over a decade) so that's a solid, tested starting point for the Mailman 3.0 implementation. Incidentally, dynamic sublists are a list-wide setting that the admin would have to enable, the way they're currently written, and that's one of those things I personally would keep the same. Much like topics, dlists do require some training on the part of your users (and from experience, I'd say the amount of training and chasing down the "but you need to post this right next time!" is somewhat similar for dlists and topics) so I wouldn't want to drop people into that unless this is a feature they really want. Terri From stephen at xemacs.org Mon Nov 12 10:26:39 2012 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 12 Nov 2012 18:26:39 +0900 Subject: [Mailman-Developers] Mailman 3: dlist integration In-Reply-To: <50A09EC6.5090704@zone12.com> References: <509EE94E.6070303@zone12.com> <87625bhajm.fsf@uwakimon.sk.tsukuba.ac.jp> <50A09EC6.5090704@zone12.com> Message-ID: <87ip9b894g.fsf@uwakimon.sk.tsukuba.ac.jp> Terri Oda writes: > > Is it possible to split or merge threads? > Posters can split off a thread at any time by just replying to +new > instead of the existing thread. So if somebody is subscribed to the old thread, and their default is not to automatically subscribe to new threads, they lose track of the new thread? > There is currently no way to merge threads. OK. That's hard to do (and keep users happy). > I can't think of a better way to handle [threads that migrate from > one list to another] off the top of my head for much the same > reasons that correctly threading archives is hard. As long as you don't try to support merging threads, and people provide accurate reference or in-reply-to headers, archive threading is pretty much a solved problem AFAIK, as long as you have access to *all* the lists. What's hard to do at the server end is provide killfiles. That's also a solved problem on the client end, but for some reason people want the server to do it for them. From follybeachris at gmail.com Mon Nov 12 20:48:39 2012 From: follybeachris at gmail.com (Chris Cargile) Date: Mon, 12 Nov 2012 14:48:39 -0500 Subject: [Mailman-Developers] Mailman 3.0 fresh install - problems from python interpreter In-Reply-To: References: <20120605220944.67b50481@resist.wooz.org> <50A14FBC.7030701@gmail.com> Message-ID: In case others might be interested and appreciating a bit of help recalling what the search feature's development status is at the moment, this email spawned from a thread in June 2012, here: http://www.mail-archive.com/mailman-developers at python.org/msg12921.html > > On Mon, Nov 12, 2012 at 2:36 PM, Chris Cargile wrote: > >> ** >> I have been facing some of the installation/configuration/CLI issues >> Jessy mentions and agree the documentation could call out a bit more >> explicitly the proper steps but all the same good progress is being made! >> >> I'm hoping to complete the same 'create new mailing lists' step that >> Jessy pointed to >> http://packages.python.org/mailman/src/mailman/commands/docs/create.html, >> but I did not install via the python-installation procedure.. rather, I >> completed the Ubuntu tutorial located here: >> https://help.ubuntu.com/12.04/serverguide/mailman.html >> >> A mailman instance is successfully running, but this installation has >> left me without (as far as I can find) certain bin/ commands to be run in >> the interpreter, including mailman (as in, e g: 'mailman info'). I am >> wondering if there is a simple way to access the functionality described in >> the python docs pages, such that importing the various zope,etc modules >> will work in the CLI, without rebuilding mailman from scratch (using the >> python build-out procedure) >> >> I hope I can make this work, but seeing as how my end-goal is to better >> learn the basics of a programming language that is probably better-position >> for future viability (-->Python) than ones I'd taken up previously (ie: >> php), in addition to developing for the mailman utility, I will remain in a >> good position either way :) >> >> - my end-goal with this endeavor is the create a script that accepts >> mlist as the argument and generates a separate file for each email >> (pickle?) in the list archive. Achieving this will allow me to more easily >> create the search interface I'm after which I'm hoping will become a >> proof-of-concept implementation for the "search engine for archives" >> to-do list feature . >> >> As I interpret this goal, another way of saying this I think is: "it >> would be great if list administrators could drop-in a module to deploy an >> html form-search interface that indexes previous archives, in addition to >> allowing mail-archive.com to archive future messages to the list." >> > > From gphemsley at gmail.com Fri Nov 23 21:55:11 2012 From: gphemsley at gmail.com (Gordon P. Hemsley) Date: Fri, 23 Nov 2012 15:55:11 -0500 Subject: [Mailman-Developers] Using bracketed prefixes in subject as filters Message-ID: I filed a request for enhancement about using bracketed prefixes in subjects as filters: https://bugs.launchpad.net/mailman/+bug/1082495 Barry mentioned that I should raise the issue with regard to the dlist discussion, I presume because my proposal overlaps and/or conflicts with it. However, the only things I know about what a "dlist" even is has been garnered from skimming the four messages on the topic in the archive, and it's not clear to me they my idea is necessarily compatible with dlists. (They seem to be exclusive proposals that may handle the same usecase.) I've only just subscribed to this list to participate in this discussion, and my knowledge of the inner workings of mailman is fairly limited. But I present to you the contents of the RFE I filed, in order to facilitate discussion: =========== Many large mailing lists use bracketed prefixes in subjects as a way to filter messages into smaller buckets, allowing some subscribers to read all mail sent to the list while allowing others to filter messages (in their mail client) to read only the messages they are interested in. For example, the W3C's www-style mailing list uses these tags to filter messages based on which CSS spec they refer to. Thus, a subject line that begins "[css3-fonts]" will be assumed to be about only the css3-fonts spec, with a target audience of only those interested in that particular spec and not, say, the css3-flexbox spec (whose subject lines would be prefixed with "[css3-flexbox]"). To handle this, the Mailman archive interface would provide an option to filter only on particular prefixes (as well as messages that don't have any prefixes), allowing a user of the archive to use it as they otherwise would, but filtering the output such that they only see the messages they want to see, instead of the whole archive. In addition, it would be helpful to allow mailing lists to automatically prefix subject lines when the message is sent to an e-mail address using a plus alias. For example, sending mail to www-style+css3-fonts at w3.org would prefix the subject line of the message with "[css3-fonts]" in the message sent to subscribers and in the archive, whereas sending mail to www-style+css3-flexbox at w3.org would prefix the message with "[css3-flexbox]". It should also be allowed to have multiple prefixes on a message, and having such messages be treated as if they had any prefix individually. In terms of plus aliasing, there are two ways to handle it: (1) allow aliases to specify multiple prefixes in a plus alias using some separator (e.g. a comma: www-style+css3-fonts,css3-flexbox at w3.org); or (2) detecting and intercepting when a single message was sent to multiple e-mail addresses with different plus aliases for a single mailing list (e.g. sending the same e-mail to both www-style+css3-fonts at w3.org and www-style+css3-flexbox at w3.org), treating it as a single message with multiple subject prefixes when sent to subscribers or stored in the archive. Now, I understand that this is likely a huge undertaking, but I think it would go a long way to helping users with large and diverse mailing lists. [EDIT: It appears the W3C may not actually use Mailman. But my point is still the same, so take my usage of W3C e-mails as a hypothetical example, if necessary.] =========== (My first thinking on the matter arose when dealing with the WHATWG mailing list, which I know uses Mailman. I don't subscribe to any W3C mailing lists right now, so I didn't realize that W3C may not use Mailman; it was only my use of the W3C archives that prompted me to file my original idea as a Mailman RFE.) Regards, Gordon -- Gordon P. Hemsley me at gphemsley.org http://gphemsley.org/ ? http://gphemsley.org/blog/ From stephen at xemacs.org Sat Nov 24 09:14:58 2012 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 24 Nov 2012 17:14:58 +0900 Subject: [Mailman-Developers] Using bracketed prefixes in subject as filters In-Reply-To: References: Message-ID: <87haof5se5.fsf@uwakimon.sk.tsukuba.ac.jp> Gordon P. Hemsley writes: > Thus, a subject line that begins "[css3-fonts]" will be assumed to > be about only the css3-fonts spec, [...] and not, say, the > css3-flexbox spec (subject lines prefixed with "[css3-flexbox]"). > > To handle this, the Mailman archive interface would provide an option > to filter only on particular prefixes (as well as messages that don't > have any prefixes), allowing a user of the archive to use it as they > otherwise would, but filtering the output such that they only see the > messages they want to see, instead of the whole archive. This would not be a big deal to implement in HyperKitty (though I don't personally have the necessary sum of time and interest). If you can wait until next August for product, it would make an excellent GSoC project, I suspect, and probably you could get a patch for Mailman 2's Pipermail archiver from the same GSoC project. > In addition, it would be helpful to allow mailing lists to > automatically prefix subject lines when the message is sent to an > e-mail address using a plus alias. > > For example, sending mail to www-style+css3-fonts at w3.org would prefix > the subject line of the message with "[css3-fonts]" in the message > sent to subscribers and in the archive, whereas sending mail to > www-style+css3-flexbox at w3.org would prefix the message with > "[css3-flexbox]". Yuck. (That's a technical term. :-) This is rather un-Pythonic (violates the "there should be one (and preferably only one) obvious way to do it" principle, AKA "TOOWTDI"). The conventional way to configure this in Mailman would be to have two normal mailing lists (css3-fonts and css3-flexbox), and one umbrella list (www-style) which subscribes to the css-* lists but doesn't receive posts directly. People who prefer to have the server make decisions for them would subscribe directly to css-* lists. Those who prefer to filter themselves would subscribe to www-style. > > It should also be allowed to have multiple prefixes on a message, [...]. > Now, I understand that this is likely a huge undertaking, but I think > it would go a long way to helping users with large and diverse mailing > lists. It's still not a huge undertaking, and would be suitable for a GSoC project IMO. However, this can also easily be handled by umbrella lists; you just cross-post to the various sub-lists. In the case of Mailman 3, it should also be possible to de-dupe automatically at the server side for subscribers with multiple subscriptions. This would be a GSoC- scale project too. For Mailman 2, it *would* be a pretty big project to de-dupe accurately, although "sibling lists" can help with this. From aurelien at bompard.org Wed Nov 28 11:34:02 2012 From: aurelien at bompard.org (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 28 Nov 2012 11:34:02 +0100 Subject: [Mailman-Developers] First alpha release of HyperKitty Message-ID: <50B5E89A.3090508@bompard.org> Hello Mailman devs ! HyperKitty, the Mailman 3 archiver, is advancing at a reasonable pace, and the time has come for its first alpha release. The code has been published on PyPI : - http://pypi.python.org/pypi/HyperKitty/ - http://pypi.python.org/pypi/KittyStore I've also written some installation and development documentation (with Sphinx), it's online at ReadTheDocs.org: http://hyperkitty.readthedocs.org/ If you're interested in HyperKitty, want to test it, or even contribute to it, it's now pretty easy, just follow the procedure described in the doc. Django hackers, and even regular Python hackers, will find it quite common. Please report any bug you can find on our tracker project page: https://fedorahosted.org/hyperkitty/newticket I hope you'll like it ! Aur?lien -- http://aurelien.bompard.org ~~~~~~ jabber: aurelien at bompard.org "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From barry at list.org Thu Nov 29 18:31:25 2012 From: barry at list.org (Barry Warsaw) Date: Thu, 29 Nov 2012 12:31:25 -0500 Subject: [Mailman-Developers] First alpha release of HyperKitty In-Reply-To: <50B5E89A.3090508@bompard.org> References: <50B5E89A.3090508@bompard.org> Message-ID: <20121129123125.6266a2de@resist.wooz.org> On Nov 28, 2012, at 11:34 AM, Aur?lien Bompard wrote: >HyperKitty, the Mailman 3 archiver, is advancing at a reasonable pace, >and the time has come for its first alpha release. Fantastic! Congratulations Aur?lien and everyone else who has contributed. I'm planning on pulling this down and giving it a run asap. -Barry From terri at zone12.com Thu Nov 29 21:49:51 2012 From: terri at zone12.com (Terri Oda) Date: Thu, 29 Nov 2012 13:49:51 -0700 Subject: [Mailman-Developers] Dec 15th Mailman/Postorius/Hyperkitty hackathon Message-ID: <50B7CA6F.9070201@zone12.com> Well, our last online hackathon was sufficiently fun that Florian and I think we should do it again. So... You're all cordially invited to join us on #mailman on freenode on Saturday Dec 15th to do some Mailman-related hacking, project planning, and maybe some task creation for GSoC 2013. I'll be in Albuquerque on US Mountain time (UTC -700) and will probably be online from around 10am-11pm, as well as probably some the night before. Possibly helpful: http://timeanddate.com/worldclock/meetingtime.html?month=12&day=15&year=2012&p1=394&p2=37&p3=248&iv=0 Mark your calendars! Terri From barry at list.org Thu Nov 29 23:27:44 2012 From: barry at list.org (Barry Warsaw) Date: Thu, 29 Nov 2012 17:27:44 -0500 Subject: [Mailman-Developers] Dec 15th Mailman/Postorius/Hyperkitty hackathon In-Reply-To: <50B7CA6F.9070201@zone12.com> References: <50B7CA6F.9070201@zone12.com> Message-ID: <20121129172744.5c2fb681@limelight.wooz.org> On Nov 29, 2012, at 01:49 PM, Terri Oda wrote: >Well, our last online hackathon was sufficiently fun that Florian and I think >we should do it again. > >So... You're all cordially invited to join us on #mailman on freenode on >Saturday Dec 15th to do some Mailman-related hacking, project planning, and >maybe some task creation for GSoC 2013. > >I'll be in Albuquerque on US Mountain time (UTC -700) and will probably be >online from around 10am-11pm, as well as probably some the night before. Great idea. I've marked my calendar! -Barry