From barry at list.org  Mon Mar  5 20:23:04 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 5 Mar 2012 14:23:04 -0500
Subject: [Mailman-Developers] Pycon 2012 and Mailman 3 plans
Message-ID: <20120305142304.1c403bea@limelight.wooz.org>

With Pycon 2012 coming up in the next few days, and most of the core Mailman
developers attending the sprints[1], we have a opportunity to reach some
important milestones with Mailman 3.

You are of course invited to join us.  Please sign up on the project page
below so we can make the appropriate plans.

Don't forget to come to my talk on Saturday at 4:55pm local time[2].

We'll have two main goals for the sprint, and possibly a third:

 - Do a face-to-face integration of the web ui for MM3, identifying any
   concerns or missing functionality in the API, reviewing the ui design,
   fix related bugs, etc.
 - Solidify the core engine so that I can release beta 1.
 - Possibly, make progress on the next-gen archiver.

Yes, you read that right.  At long last, I believe the core engine is solid
enough to move into beta.  This means we'll freeze the database schema and use
the migration mechanism for any future updates, and we'll also feature freeze
so we can concentrate on bug fixing[3].  So beta 1 is planned for during or
just after the sprints.

Finally, I have put up a test server, which you are invited to join and use.
Right now, you only have access to the email command interface, meaning you
must join and leave the mailing list via email commands and confirmations.
Once joined, you can of course post to the list.

Note that this list is running on a virtual machine, so it, the domain, or the
Mailman service can disappear at any time.  Occasionally, I'll stop the
system, run it in debug mode (meaning your posts will not go to the list),
update the software, etc.  If something looks weird, please try again, or
email me, or file a bug on Launchpad[4].  Please include the original email or
at least the Message-Id of the message you sent that caused the problem.

I will be watching the logs when I can.  Be good citizens and reasonable
users.  Abuse will not be tolerated and will get you banned at the MTA.

  - Subscribe by sending a message to playground-join at groon.org
  - Unsubscribe by sending a message to playground-leave at groon.org
  - Get help by sending a message to playground-request at groon.org with the
    word 'help' (sans quotes) in the Subject
  - Post to the list at playground at groon.org

Enjoy, and I hope to see you at Pycon.

Cheers,
-Barry


[1] https://us.pycon.org/2012/community/sprints/projects/
[2] I guess I should write it, eh? <wink>
    https://us.pycon.org/2012/schedule/
[3] Of course, I get to decide what's a bug and what's a missing feature :)
[4] https://bugs.launchpad.net/mailman/+filebug
    Please tag the bug with 'mailman3'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120305/4e51c1e5/attachment.pgp>

From a.badger at gmail.com  Mon Mar  5 22:33:33 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 5 Mar 2012 13:33:33 -0800
Subject: [Mailman-Developers] Pycon 2012 and Mailman 3 plans
In-Reply-To: <20120305142304.1c403bea@limelight.wooz.org>
References: <20120305142304.1c403bea@limelight.wooz.org>
Message-ID: <20120305213333.GI28286@unaka.lan>

On Mon, Mar 05, 2012 at 02:23:04PM -0500, Barry Warsaw wrote:
>  - Possibly, make progress on the next-gen archiver.
> 
Greetings, I'l be there and looking to talk with some people about this.
I work with a talented interaction designer that's been thinking about
better UI for archives for a few years.  Hopefully I'll have a prototype
so people can see some of her ideas in practice and then we can look at how
to improve on that.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120305/bf53a9ef/attachment.pgp>

From stephen at xemacs.org  Tue Mar  6 02:43:40 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 06 Mar 2012 10:43:40 +0900
Subject: [Mailman-Developers] Pycon 2012 and Mailman 3 plans
In-Reply-To: <20120305213333.GI28286@unaka.lan>
References: <20120305142304.1c403bea@limelight.wooz.org>
	<20120305213333.GI28286@unaka.lan>
Message-ID: <87zkbua4hf.fsf@uwakimon.sk.tsukuba.ac.jp>

Toshio Kuratomi writes:
 > On Mon, Mar 05, 2012 at 02:23:04PM -0500, Barry Warsaw wrote:
 > >  - Possibly, make progress on the next-gen archiver.
 > > 
 > Greetings, I'l be there and looking to talk with some people about this.

I'll be there, and I'm definitely interested in the archiver.  While
pipermail has been fine for my lists so far, I'd really like a few
features that it can't give us.  And of course it's been a sore point
for years.

I suspect it's something that we could get lucky on and produce best
of breed, too.  I can't say I'm real happy with any of the commercial
archivers or Gmane.

From jagannathante at gmail.com  Thu Mar  8 18:39:22 2012
From: jagannathante at gmail.com (Jagannathan Tiruvallur Eachambadi)
Date: Thu, 8 Mar 2012 23:09:22 +0530
Subject: [Mailman-Developers] fixing the bug 837700(
	https://bugs.launchpad.net/mailman/+bug/837700 )
Message-ID: <CABzJUX6kFpRFKU0M7Cn5uLangSW=KCYm7Wc=MYcdPot6y5HSxA@mail.gmail.com>

Barry,

In the bug 837700, I have implemented the suggestions you have made in the
comment in launchpad. I am unable to test the bug in the first place. Is
there a way in which I can reproduce the bug. Since there are only three
legitimate users who are are hard coded in the Rest API, how can I give
them preferred addresses.

Regards,
Jagan

From abdulraufhaseeb at gmail.com  Sun Mar 11 05:38:02 2012
From: abdulraufhaseeb at gmail.com (abdul rauf)
Date: Sun, 11 Mar 2012 10:08:02 +0530
Subject: [Mailman-Developers] gsoc-2012
Message-ID: <CADfPSp_-TZOFB2gL33Q4cUC5jjKT5osOGSNy7q0CEOqpwDFAVg@mail.gmail.com>

Hi,
I was going through ideas page of mailman for GSoC 2012. I would like
to work with mailman.
If there are more ideas i would like to see it. Currently i am 3rd
year of under-graduation at K.B.N.C.E Gulbarga.

From barry at list.org  Mon Mar 12 06:15:12 2012
From: barry at list.org (Barry Warsaw)
Date: Sun, 11 Mar 2012 22:15:12 -0700
Subject: [Mailman-Developers] Pycon 2012 sprint start time
Message-ID: <20120311221512.3ee04c0f@resist>

Pycon 2012 sprinters,

I will probably be in the sprint room by 9:30am tomorrow, but we won't
officially start until 10am.  Looking forward to seeing everyone there!

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120311/2bbcdd8d/attachment.pgp>

From mark at msapiro.net  Mon Mar 12 07:00:56 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 11 Mar 2012 23:00:56 -0700
Subject: [Mailman-Developers] Pycon 2012 sprint start time
In-Reply-To: <20120311221512.3ee04c0f@resist>
References: <20120311221512.3ee04c0f@resist>
Message-ID: <4F5D9118.9060208@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/11/2012 10:15 PM, Barry Warsaw wrote:
> Pycon 2012 sprinters,
> 
> I will probably be in the sprint room by 9:30am tomorrow, but we
> won't officially start until 10am.  Looking forward to seeing
> everyone there!


Cool! I'll be there by 9:30 too.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPXZEYVVuXXpU7hpMRAuR8AKCMLm5fEicchIC9cXRov6P+vJb03ACgg80H
UcvP/tqRmKQR5Pw81t+CkKw=
=tk67
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Mon Mar 12 13:44:18 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 12 Mar 2012 05:44:18 -0700
Subject: [Mailman-Developers] Pycon 2012 sprint start time
In-Reply-To: <4F5D9118.9060208@msapiro.net>
References: <20120311221512.3ee04c0f@resist>
	<4F5D9118.9060208@msapiro.net>
Message-ID: <CAL_0O18RAPCK+avN7kBVO=xgxeDb3rOLpQhHF_ntKJTP-3Zkhw@mail.gmail.com>

I will definitely be there around 9:30, but I have a 10am appointment,
should be back around 11am.

On Sun, Mar 11, 2012 at 11:00 PM, Mark Sapiro <mark at msapiro.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 3/11/2012 10:15 PM, Barry Warsaw wrote:
> > Pycon 2012 sprinters,
> >
> > I will probably be in the sprint room by 9:30am tomorrow, but we
> > won't officially start until 10am.  Looking forward to seeing
> > everyone there!
>
>
> Cool! I'll be there by 9:30 too.
>
> - --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFPXZEYVVuXXpU7hpMRAuR8AKCMLm5fEicchIC9cXRov6P+vJb03ACgg80H
> UcvP/tqRmKQR5Pw81t+CkKw=
> =tk67
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/stephen%40xemacs.org
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From p at state-of-mind.de  Mon Mar 12 13:47:58 2012
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Mon, 12 Mar 2012 13:47:58 +0100
Subject: [Mailman-Developers] Pycon 2012 sprint start time
In-Reply-To: <20120311221512.3ee04c0f@resist>
References: <20120311221512.3ee04c0f@resist>
Message-ID: <20120312124755.GB9321@state-of-mind.de>

* Barry Warsaw <barry at list.org>:
> Pycon 2012 sprinters,
> 
> I will probably be in the sprint room by 9:30am tomorrow, but we won't
> officially start until 10am.  Looking forward to seeing everyone there!

Wish I was there! Greetings from Cologne, Germany. :)

p at rick

-- 
state of mind ()

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120312/64d9c762/attachment.pgp>

From benedict.stein at googlemail.com  Mon Mar 12 16:20:33 2012
From: benedict.stein at googlemail.com (Benedict Stein)
Date: Mon, 12 Mar 2012 17:20:33 +0200
Subject: [Mailman-Developers] Pycon 2012 sprint start time
In-Reply-To: <20120312124755.GB9321@state-of-mind.de>
References: <20120311221512.3ee04c0f@resist>
	<20120312124755.GB9321@state-of-mind.de>
Message-ID: <4F5E1441.6040703@gmail.com>

Well I'd say it's afternoon now, work just finished (17:19 - JNB Time)
so it's 1:10 left until it's IRC time :)

Gonna hear from all of you in a short while

On 12/03/2012 14:47, Patrick Ben Koetter wrote:
> * Barry Warsaw <barry at list.org>:
>> Pycon 2012 sprinters,
>>
>> I will probably be in the sprint room by 9:30am tomorrow, but we won't
>> officially start until 10am.  Looking forward to seeing everyone there!
> Wish I was there! Greetings from Cologne, Germany. :)
>
> p at rick
>
>
>
> _______________________________________________
> 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/benedict.stein%40googlemail.com
>
> Security Policy: http://wiki.list.org/x/QIA9

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120312/44f2d996/attachment.pgp>

From fmouse at fmp.com  Mon Mar 12 19:54:44 2012
From: fmouse at fmp.com (Lindsay Haisley)
Date: Mon, 12 Mar 2012 13:54:44 -0500
Subject: [Mailman-Developers] courier-to-mailman.py
Message-ID: <1331578484.22595.21.camel@moomba.fmp.com>

I just got an email from a fellow in Germany wanting to know where he
could find courier-to-mailman.py, a script I contributed to mailman some
time ago and which is included in the distribution, but apparently not
parsed for replacement tokens and installed in the contrib directory at
install time.

It might be a good idea to patch configure.in with the proper line to
take care of this:

--- configure.in.old	2012-03-12 13:41:57.512455181 -0500
+++ configure.in	2012-03-12 13:42:21.252451587 -0500
@@ -681,6 +681,7 @@
 bin/rb-archfix \
 contrib/check_perms_grsecurity.py \
 contrib/qmail-to-mailman.py \
+contrib/courier-to-mailman.py \
 contrib/rotatelogs.py \
 cron/bumpdigests \
 cron/checkdbs \

... and run autoconf so that the distributed configure file reflects
this change.

You have the equivalent script for qmail properly generated, but not the
courier script.  Qmail is pretty much obsolete these days, while courier
is under active development and is widely used, notably outside the US.
I've been using the courier-to-mailman.py script for the better part of
10 years.

-- 
Lindsay Haisley       | "Everything works if you let it"
FMP Computer Services |
512-259-1190          |          --- The Roadie
http://www.fmp.com    |


From mark at msapiro.net  Tue Mar 13 03:10:03 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 12 Mar 2012 19:10:03 -0700
Subject: [Mailman-Developers] courier-to-mailman.py
In-Reply-To: <1331578484.22595.21.camel@moomba.fmp.com>
Message-ID: <PC195201203121910030604296fea5f@Notebook-09>

Lindsay Haisley wrote:

>I just got an email from a fellow in Germany wanting to know where he
>could find courier-to-mailman.py, a script I contributed to mailman some
>time ago and which is included in the distribution, but apparently not
>parsed for replacement tokens and installed in the contrib directory at
>install time.
>
>It might be a good idea to patch configure.in with the proper line to
>take care of this:


I have patched configure(.in) as you suggest, but I wonder if this will
solve the problem you are trying to address. It will result in a
build/courier-to-mailman.py in the 'unpack and configure' directory
with the replacement tokens expanded thus putting
courier-to-mailman.py on an equal footing with qmail-to-mailman.py,
but 'make install' does not install the contrib/ directory in the
actual Mailman installation.

Thus, the configured script will only be found in the build/ directory
in the 'unpack and configure' directory.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From andrea.crotti.0 at gmail.com  Wed Mar 14 17:10:25 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Wed, 14 Mar 2012 16:10:25 +0000
Subject: [Mailman-Developers] mailman UI
Message-ID: <4F60C2F1.2030403@gmail.com>

Look what I found reading the news, someone wants to make a social 
network out of Mailman ;)

http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/

From barry at list.org  Fri Mar 16 06:41:58 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 15 Mar 2012 22:41:58 -0700
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
	scrubbing in Mailman 3
Message-ID: <20120315224158.3afa4323@resist>

There's an aspect of the scrubber that isn't going to work in a Mailman 3
world where we have multiple, possibly external, archivers and especially
where we don't have such tight integration with Pipermail (or Pipermail at all
<wink>).

We can still scrub messages of unwanted content type, but we can't save those
parts on the file system and calculate a URL into Pipermail to display them.

I can think of a few ways to handle this.

The easiest thing to do, and what I will probably do in my
'death-to-pipermail' branch is to simply scrub out the unwanted parts *after*
a copy of the message is sent to the archive queue, but *before* the message
is sent to the digest, usenet, and outgoing queues.

This makes sense because with a model of external archiving, those archivers
may make different decisions about what should be removed or displayed from
the original message.  We can still include a little blurb saying that a part
was scrubbed out, and since the messages can have the pre-calculated url to
the message in one or more archivers, the user is always free to just click on
the url to see the full message, displayed with whatever policy the archiver
is configured with.

One possibility is to save the scrubbed part inside the core and provide a url
to the REST API for accessing this attachment.  This can't be inserted into
the scrubbed message directly though because this would be a non-public url to
the resource, and it would have to be proxied by the web ui.  We need better
configuration for integrating the web ui with the core any way (e.g. to
calculate the url to the user's options page), so this could be part of that.
The interactions are trickier though because you would then have to inform the
web ui that there's a new attachment it should proxy.

The other, more elaborate option is to define an IScrubber interface, or
alternatively a "primary" IArchiver, that the message can pass through, which
would give it an opportunity to provide urls for each of the parts that will
be scrubbed out.  This is trickier because there can really be only one such
thing defined in the system.  I think it would be confusing if you received a
message that had something like this:

    text/html part scrubbed, view it at one of the following:
    http://example.com/attachments/foo.html
    http://example.org/some/extra/path/bar.html
    http://another.archive.example.net/whatever/baz.html

Besides, this may be nearly impossible to do without in-band communication
with that external archiver, which is exactly what the RFC 5064 +
message-id-hash was supposed to avoid.   I think we definitely don't want to
have to force such in-band communications to occur in order to scrub messages
of unwanted parts.

For now, I'm going to try to implement sending an unscrubbed copy of the
message to the archivers and just throwing up our hands for the copy of the
message sent to the list members.  The nice side-effect of this is that it
makes the scrubber *way* simpler!

Any other suggestions?

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120315/81576dbb/attachment.pgp>

From barry at list.org  Fri Mar 16 07:20:41 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 15 Mar 2012 23:20:41 -0700
Subject: [Mailman-Developers] Thanks for sprinting at Pycon 2012!
Message-ID: <20120315232041.3f941677@resist>

I'll be blogging in more detail about the Pycon 2012 Mailman sprint once I've
recovered from my sleep deprived jetlagged fog, but I just wanted to send a
quick note of thanks to all the folks who attended:

Andrea Crotti
Florian Fuchs
Toshio Kuratomi
Daniel Mizyrycki
Terri Oda
Mark Sapiro
Stephen Turnbull

We made some *incredible* progress on the Mailman 3 core and web-ui.  I saw
demos of the latter that look fantastic.  It was a pleasure to hang out and
hack with you guys for a few days.  Thanks also to M?ir?n Duffy who joined us
on mumble to share with us 16 of her 32 very cool brainstorms on Mailman's web
ui.

Special thanks to Larry Hastings for helping us find some nice eats, even if I
was an anti-social stick-in-the-mud after the Greek and Thai places.  That's
what Tamari sauce will do to you. :)

Alpha releases of the web ui and a beta of the core will be coming next week
once we're all recovered.  Stay tuned.

Cheers,
-Barry

P.S. I may even have a few pictures to post later too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120315/fbc6d994/attachment.pgp>

From mark at msapiro.net  Fri Mar 16 18:11:10 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 16 Mar 2012 10:11:10 -0700
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120315224158.3afa4323@resist>
References: <20120315224158.3afa4323@resist>
Message-ID: <4F63742E.9010902@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/15/2012 10:41 PM, Barry Warsaw wrote:
> 
> We can still scrub messages of unwanted content type, but we can't
> save those parts on the file system and calculate a URL into
> Pipermail to display them.


There are two things going on. There is content filtering, i.e.,
removal from the message of parts with unwanted MIME types or filename
extensions. These parts are simply removed by pipeline/mime_delete.py
(which probably needs some changes ported from 2.1, aargh...).

Then there is what pipeline/scrubber.py does with the remaining
message which is remove those message parts which can't be rendered
well in a flat, text/plain message and store them aside and replace
them by links in the message. The part we can't do in MM 3 is
calculate a URL to display/download them.


> I can think of a few ways to handle this.
> 
> The easiest thing to do, and what I will probably do in my 
> 'death-to-pipermail' branch is to simply scrub out the unwanted
> parts *after* a copy of the message is sent to the archive queue,
> but *before* the message is sent to the digest, usenet, and
> outgoing queues.


I'm not sure about the *before* with respect to usenet and digest and
certainly outgoing. Currently in 2.1, we don't scrub (as opposed to
content filter) non-digest deliveries unless scrub_nondigest is Yes.
We maybe should just drop that option.

We also don't scrub messages for the MIME digest.

I also don't think we scrub messages destined for usenet. I think we
let usenet worry about that in the same way we propose to let whatever
archiver is configured worry about it.

I don't see a need to handle these differently in MM 3.


[...]
> For now, I'm going to try to implement sending an unscrubbed copy
> of the message to the archivers and just throwing up our hands for
> the copy of the message sent to the list members.  The nice
> side-effect of this is that it makes the scrubber *way* simpler!


Perhaps we could keep the scrubber as is except for modifying it to
not store scrubbed parts and put some kind of apology in the message
rather than the link to the no longer stored content.

Then my lp:~msapiro/mailman/scrubber-fix branch would still be relevant ;)

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD4DBQFPY3QuVVuXXpU7hpMRAkN2AKCVzhwvBUITlLVgDMwg+V+da0cyJACXed7Q
jAvaD7jeN2/4armc/nIxBw==
=MsB3
-----END PGP SIGNATURE-----

From mark at msapiro.net  Fri Mar 16 18:41:06 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 16 Mar 2012 10:41:06 -0700
Subject: [Mailman-Developers] Thoughts on processing for pre-approved
	messages
Message-ID: <4F637B32.100@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've had several thoughts on what is now (in MM 3) done by
rules/approved.py.

There is a moderator_password list attribute which can be used in a
(X-)Approve(d): header or first body line pseudo-header to pre-approve
a list post.

I've gone around a bit on this and I've concluded this is analogous to
the list poster password I implemented for 2.1. Presumably we don't
want to allow this password to be used to authenticate to the web ui.
We may want to allow it for authentication for certain email commands.
I'm not sure about that one.

My basic thought is we know who allegedly sent the post (maybe we have
a few places to check - the poster might legitimately spoof the
From:), so we can find a user who owns that address, see if the user
has a moderator or admin role for this list, and validate the header
password against that user's password. We *don't* want to do this
because the user doesn't want to send her own personal password in a
plain text email header. So we use this relatively easily changed and
not very capable moderator_password instead.

So far, so good.

Now I see some issues with what rules/approved.py does. It checks for
the header and validates the password. This is good. It also removes
any header or body lines containing the pseudo-header from the
message. Architecturally, this latter operation belongs in the
pipeline, not in a chain rule. This seems to say we need both a rules
module and a pipeline module (or maybe the existing
pipeline/cleanse.py) to do this, and in the interest of DRY, we really
need a mlist.check_approved(msg, clean=True|False) method to do the
heavy lifting. Unfortunately, this adds complexity and potential for
security lapses if the rule hits but the pipeline doesn't remove the
authentication.

Thoughts?

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPY3sxVVuXXpU7hpMRAodWAKCCcHOzCm3n7Ik9VUVapsUAHTvONwCghcoN
qbND9+Opjm2D+Lb5PTqxIpg=
=4wV2
-----END PGP SIGNATURE-----

From andrea.crotti.0 at gmail.com  Fri Mar 16 19:05:19 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Fri, 16 Mar 2012 18:05:19 +0000
Subject: [Mailman-Developers] bugs on launchpad
Message-ID: <4F6380DF.4000708@gmail.com>

Hi everyone,
I filed in two bugs today:
https://bugs.launchpad.net/mailman/+bug/956889
https://bugs.launchpad.net/mailman/+bug/956384

because I thought we could have a discussion there about these topics.
But now I was wondering if it is a good idea, is it maybe better to 
write on the mailing list for
these kind of things??

PS. ironically today they asked me for the first time in my life to 
check why Mailman was not
working on a Linux server. The problem was that /var was full, but well 
knowing more about
Mailman certainly helped :D

From andrea.crotti.0 at gmail.com  Fri Mar 16 21:27:50 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Fri, 16 Mar 2012 20:27:50 +0000
Subject: [Mailman-Developers] programming languages
Message-ID: <4F63A246.4060906@gmail.com>

I just noticed that on the launchpad page the programming languages appears:

Programming Languages:
    Python, C

but I don't see any trace of C...
Cheers,
Andrea


From mark at msapiro.net  Sat Mar 17 00:28:22 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 16 Mar 2012 16:28:22 -0700
Subject: [Mailman-Developers] programming languages
In-Reply-To: <4F63A246.4060906@gmail.com>
References: <4F63A246.4060906@gmail.com>
Message-ID: <4F63CC96.3070605@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/16/2012 1:27 PM, Andrea Crotti wrote:
> I just noticed that on the launchpad page the programming
> languages appears:
> 
> Programming Languages: Python, C
> 
> but I don't see any trace of C...


Compiled C wrappers are used in Mailman 2.1 to ensure that
unauthorized local server users can't run the web UI and mail posting
scripts. For more information on how this works, see
<http://wiki.list.org/x/tYA9>.

When Mailman 3 reaches general release, we can deprecate Mailman 2.1
and remove the note about C.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPY8yVVVuXXpU7hpMRAr9tAKCsuV9YucmY1QQRipIVD5RlSsyrkwCglvTg
bwVCt9jqmcUSZ+QeKWG/Uxs=
=03Br
-----END PGP SIGNATURE-----

From barry at list.org  Sat Mar 17 18:05:00 2012
From: barry at list.org (Barry Warsaw)
Date: Sat, 17 Mar 2012 13:05:00 -0400
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F63742E.9010902@msapiro.net>
References: <20120315224158.3afa4323@resist>
	<4F63742E.9010902@msapiro.net>
Message-ID: <20120317130500.7b9e4584@resist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mar 16, 2012, at 10:11 AM, Mark Sapiro wrote:

>There are two things going on. There is content filtering, i.e.,
>removal from the message of parts with unwanted MIME types or filename
>extensions. These parts are simply removed by pipeline/mime_delete.py
>(which probably needs some changes ported from 2.1, aargh...).

Yeah, that's embarrassing ;).  I've started down the road of adding unittests
for the code in that module.  You'll see the start of that land momentarily.

>Then there is what pipeline/scrubber.py does with the remaining
>message which is remove those message parts which can't be rendered
>well in a flat, text/plain message and store them aside and replace
>them by links in the message. The part we can't do in MM 3 is
>calculate a URL to display/download them.

Yep.

>> The easiest thing to do, and what I will probably do in my 
>> 'death-to-pipermail' branch is to simply scrub out the unwanted
>> parts *after* a copy of the message is sent to the archive queue,
>> but *before* the message is sent to the digest, usenet, and
>> outgoing queues.
>
>I'm not sure about the *before* with respect to usenet and digest and
>certainly outgoing. Currently in 2.1, we don't scrub (as opposed to
>content filter) non-digest deliveries unless scrub_nondigest is Yes.
>We maybe should just drop that option.
>
>We also don't scrub messages for the MIME digest.
>
>I also don't think we scrub messages destined for usenet. I think we
>let usenet worry about that in the same way we propose to let whatever
>archiver is configured worry about it.
>
>I don't see a need to handle these differently in MM 3.

ISTM that essence of the scrubber is to turn any remaining text/html parts
into plain text, by various means.  I think the MM2 scrubber.py module is
essentially hopeless, but the basic functionality is useful.  I've decided to
remove the scrubber in the Pipermail-eradication branch, which will also land
momentarily.  I think it would be useful though to rewrite the scrubber, boil
it down to its essential functionality, and add that to the appropriate spot
in the pipeline.

How would you like to take a crack at that?

>> For now, I'm going to try to implement sending an unscrubbed copy
>> of the message to the archivers and just throwing up our hands for
>> the copy of the message sent to the list members.  The nice
>> side-effect of this is that it makes the scrubber *way* simpler!
>
>Perhaps we could keep the scrubber as is except for modifying it to
>not store scrubbed parts and put some kind of apology in the message
>rather than the link to the no longer stored content.
>
>Then my lp:~msapiro/mailman/scrubber-fix branch would still be relevant ;)

Yeah, sorry about that. ;)  I think scrubber.py was just too nasty to
salvage.  Something much simpler would still be useful though.

Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPZMQ9AAoJEBJutWOnSwa/nFEP/iMDCM+ETv1KV36nP8r/cZfB
C50m+K1MUm/MaZpkpQI8980J96QWC1RoWvQ7sQGg2difvDvNwI0JZP4gMBJkHVUu
sO/hJZu0BDa28cC9Ww94fRX4ujelm/jesc8td0v02s54FSHUIOgxxDr+sfWNFPvI
OpLDJZVtC6LJbDt1IqI2ozxbq/b3hhuaXDbmzIsWqotyZZ/+fQDjgM4L9SCEjhrT
tDwQjFhsZmH3m58pFRkP/cOJCV2lKs0MnMGMhELHGkatMGKtVFAuP1e3r24N20yX
EVDX/7Dg20BzacNYnAVGnO28sYqb4JltRAb14+IvIMcRzIO+WKKAyJioKX3cohcT
14fhb0agtDPlMMBJw8J5AD9VEimMcZaMmISLpRY6jqkaHRu/4RxZlG3RRWtcBwdS
dN0WZnnNx6B+wV5VUJ7Q5WaDO1Xtp0jGHuT96vOQlHDm/+iwwmWWvGH3DQg1yVDN
gT2/JyLeXpDprP+qXNPLyWlMlADQjUCq7uvD51J0gcCC6aLanPnM9CuCQXdJRlFl
7g+zI9a17qCdniQcbNUgq+87ektXLi7JCp6nA1yEm0Zaelp3wJC2cB7up9ZaVR7O
SX8qpMFnfqFkvsQLC2pLH7plplHpboXWOjLALITFBzasth4hS98oHH+gOJktTKni
Erk1f+FsVR9l0Geu2q++
=z6a7
-----END PGP SIGNATURE-----

From syst3m.w0rm at gmail.com  Sat Mar 17 19:53:48 2012
From: syst3m.w0rm at gmail.com (Aamir Khan)
Date: Sun, 18 Mar 2012 00:23:48 +0530
Subject: [Mailman-Developers] Grackle archive framework
In-Reply-To: <20120216142516.69c8fbc3@resist.wooz.org>
References: <CAOb12VV0XQnxew8yZaRdZzoBFyJ1RSdOjVaB7yJCO0NVg9oRUA@mail.gmail.com>
	<20120216142516.69c8fbc3@resist.wooz.org>
Message-ID: <CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>

On Fri, Feb 17, 2012 at 12:55 AM, Barry Warsaw <barry at list.org> wrote:

> On Feb 16, 2012, at 11:40 PM, Aamir Khan wrote:
>
> >I talked to people on #launchpad-dev, as suggested by barry to investigate
> >about the possibility of using grackle as new archive framework for
> >mailman. The project isn't functional yet. There are two parts, client and
> >back-end service to store the messages. Client will hopefully be completed
> >by end of next week.
> >
> >For backend-service implementation, i am also thinking to get involved
> >during its development. They are planning to have cassandra based store
> for
> >storing the messages. Any thoughts about which backend service would be
> >ideal to store messages for mailman installations ?
>
> On IRC, we talked about a storm + Python mailbox library based backend,
> with a
> REST+JSON wsgi based application vending the data.  This would allow us to
> integrate fairly easily with MM3 I think, and would possibly better enable
> some of the archiver work being done by Terri and others.
>

I understand that we will store the messages in .mbox format. But I don't
understand why do we need to use storm for the archiving purpose.

>
> -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/syst3m.w0rm%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>



-- 
Aamir Khan | 3rd Year  | Computer Science & Engineering | IIT Roorkee

From barry at list.org  Sat Mar 17 23:54:54 2012
From: barry at list.org (Barry Warsaw)
Date: Sat, 17 Mar 2012 18:54:54 -0400
Subject: [Mailman-Developers] Grackle archive framework
In-Reply-To: <CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>
References: <CAOb12VV0XQnxew8yZaRdZzoBFyJ1RSdOjVaB7yJCO0NVg9oRUA@mail.gmail.com>
	<20120216142516.69c8fbc3@resist.wooz.org>
	<CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>
Message-ID: <20120317185454.14c38939@limelight.wooz.org>

On Mar 18, 2012, at 12:23 AM, Aamir Khan wrote:

>On Fri, Feb 17, 2012 at 12:55 AM, Barry Warsaw <barry at list.org> wrote:
>> On IRC, we talked about a storm + Python mailbox library based backend,
>> with a
>> REST+JSON wsgi based application vending the data.  This would allow us to
>> integrate fairly easily with MM3 I think, and would possibly better enable
>> some of the archiver work being done by Terri and others.
>>
>
>I understand that we will store the messages in .mbox format. But I don't
>understand why do we need to use storm for the archiving purpose.

I meant to say "maildir".  Please let's not use mbox format!  It's way too
easy to corrupt the file, as we did with a bug once in MM2.1, and we've paid
the price ever since.

As for archiving, it isn't strictly necessary to use storm, it's just a nice
lightweight ORM I happen to like.  But I think it *does* make sense to back a
full-fledged archiver with a database and a full-text search engine.  For
example, using our RFC 5064+X-Message-ID-Hash scheme, the database would
handle the lookup from hash to actual message storage location.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120317/d829ba7d/attachment.pgp>

From mark at msapiro.net  Sun Mar 18 00:43:01 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 17 Mar 2012 16:43:01 -0700
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120317130500.7b9e4584@resist.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
Message-ID: <4F652185.6010704@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/17/2012 10:05 AM, Barry Warsaw wrote:
> 
> ISTM that essence of the scrubber is to turn any remaining
> text/html parts into plain text, by various means.  I think the MM2
> scrubber.py module is essentially hopeless, but the basic
> functionality is useful.  I've decided to remove the scrubber in
> the Pipermail-eradication branch, which will also land momentarily.
> I think it would be useful though to rewrite the scrubber, boil it
> down to its essential functionality, and add that to the
> appropriate spot in the pipeline.
> 
> How would you like to take a crack at that?


Sure. Now that I actually have a bit of an idea of what's going on in
the MM 3 core, I'm happy to give it a go.

Next step for me may be to learn more about how the unittests fit
within their framework so I can create some.

Also, I need to figure out a better development platform for Windows
boxes. I had a perfect opportunity to scrap Windows all together when
I had to recover from a hard drive crash on my main development box
last year, but the dice fell the wrong way on that one.

Anyway, Cygwin is not going to cut it for MM 3. At the sprint, I tried
installing MM 3 in a vagrant VM, but there was too much missing (e.g.,
no Python.h) and even 'apt-get install python-dev' didn't fix that. I
ended up working remotely inside a virtualenv on my production server.
That actually seems to work OK, but I'm afraid that as I get deeper
into it, there will be things I need to do that I won't want to do on
my production box.

Anyway, if anyone has any suggestions for me besides the obvious "bite
the bullet now and scrap Windows - it will only be worse later", I'm
interested. I suppose I could always dual-boot Windows and some Linux
side by side.

Maybe I can organize a sprint at the next PyCon - Migrating to Linux
and killing Windows one PC at a time.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPZSGEVVuXXpU7hpMRAnRAAKDSSRUhDdQe8HoIBzOh3coe8elMIQCfU+dP
fKbzWiMB+H1wm4Jou28BV7g=
=Ehz5
-----END PGP SIGNATURE-----

From andrea.crotti.0 at gmail.com  Sun Mar 18 02:27:47 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Sun, 18 Mar 2012 01:27:47 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F652185.6010704@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
Message-ID: <4F653A13.4090206@gmail.com>

On 03/17/2012 11:43 PM, Mark Sapiro wrote:
>
> Also, I need to figure out a better development platform for Windows
> boxes. I had a perfect opportunity to scrap Windows all together when
> I had to recover from a hard drive crash on my main development box
> last year, but the dice fell the wrong way on that one.
>
> Anyway, Cygwin is not going to cut it for MM 3. At the sprint, I tried
> installing MM 3 in a vagrant VM, but there was too much missing (e.g.,
> no Python.h) and even 'apt-get install python-dev' didn't fix that. I
> ended up working remotely inside a virtualenv on my production server.
> That actually seems to work OK, but I'm afraid that as I get deeper
> into it, there will be things I need to do that I won't want to do on
> my production box.
>
> Anyway, if anyone has any suggestions for me besides the obvious "bite
> the bullet now and scrap Windows - it will only be worse later", I'm
> interested. I suppose I could always dual-boot Windows and some Linux
> side by side.
>
> Maybe I can organize a sprint at the next PyCon - Migrating to Linux
> and killing Windows one PC at a time.
>
>


I would definitively suggest to get rid of Windows, but if you don't 
want or can't
do the big step there is no reason to do a dual-boot, a just create a 
Linux virtual
machine and you're done :)

Unless you don't have much RAM is the best solution, and there are even 
pre-made
virtual machines here:
http://virtualboximages.com/

so it doesn't really take long to set up something working :)

From syst3m.w0rm at gmail.com  Sun Mar 18 06:25:19 2012
From: syst3m.w0rm at gmail.com (Aamir Khan)
Date: Sun, 18 Mar 2012 10:55:19 +0530
Subject: [Mailman-Developers] Grackle archive framework
In-Reply-To: <20120317185454.14c38939@limelight.wooz.org>
References: <CAOb12VV0XQnxew8yZaRdZzoBFyJ1RSdOjVaB7yJCO0NVg9oRUA@mail.gmail.com>
	<20120216142516.69c8fbc3@resist.wooz.org>
	<CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>
	<20120317185454.14c38939@limelight.wooz.org>
Message-ID: <CAOb12VXO0OnhO4SZS4_a40o9F8yvHcKVeuNwTgz0pp+4tHcs7g@mail.gmail.com>

On Sun, Mar 18, 2012 at 4:24 AM, Barry Warsaw <barry at list.org> wrote:

> On Mar 18, 2012, at 12:23 AM, Aamir Khan wrote:
>
> >On Fri, Feb 17, 2012 at 12:55 AM, Barry Warsaw <barry at list.org> wrote:
> >> On IRC, we talked about a storm + Python mailbox library based backend,
> >> with a
> >> REST+JSON wsgi based application vending the data.  This would allow us
> to
> >> integrate fairly easily with MM3 I think, and would possibly better
> enable
> >> some of the archiver work being done by Terri and others.
> >>
> >
> >I understand that we will store the messages in .mbox format. But I don't
> >understand why do we need to use storm for the archiving purpose.
>
> I meant to say "maildir".  Please let's not use mbox format!  It's way too
> easy to corrupt the file, as we did with a bug once in MM2.1, and we've
> paid
> the price ever since.
>

I read the difference between maildir and mbox format and it clearly states
that mbox is prone to corruption while maildir is not. Also there are more
advantages using maildir in a way that there is no file locking problem.
But since we will be storing each mail in a separate file, searching
through them will not as fast enough. Using database alone also have
problems like, it will use more hard disk, more CPU cycles will be consumed.

So, if we can store the messages in maildir format with a copy of it it
database. we can serve the searching request using database query which
will powered by full-text search engine. But then there will be problems of
synchronization between the maildir messages and  messages stored in
database. What are your thoughts about it ?

As for searching the archive, there are solutions like Elastic Search,
Solr, lucene. Can we use one of them to search directly through the maildir.

>
> As for archiving, it isn't strictly necessary to use storm, it's just a
> nice
> lightweight ORM I happen to like.  But I think it *does* make sense to
> back a
> full-fledged archiver with a database and a full-text search engine.  For
> example, using our RFC 5064+X-Message-ID-Hash scheme, the database would
> handle the lookup from hash to actual message storage location.
>
> Cheers,
> -Barry
>



-- 
Aamir Khan | 3rd Year  | Computer Science & Engineering | IIT Roorkee

From stephen at xemacs.org  Sun Mar 18 08:36:24 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 18 Mar 2012 16:36:24 +0900
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <4F6380DF.4000708@gmail.com>
References: <4F6380DF.4000708@gmail.com>
Message-ID: <CAL_0O1-VQEvqN47aqpDO-yx+exbSXXCPLopEijExEDfbp48Xzg@mail.gmail.com>

On Sat, Mar 17, 2012 at 3:05 AM, Andrea Crotti
<andrea.crotti.0 at gmail.com> wrote:
> Hi everyone,
> I filed in two bugs today:
> https://bugs.launchpad.net/mailman/+bug/956889
> https://bugs.launchpad.net/mailman/+bug/956384

These are both policy issues, I think they should be posted to the
list as well as filed on Launchpad, or instead of in the case of
continuous integration.  Once it's decided what to do about them, a
specific issue should filed to track progress.

IMO YMMV etc -- I don't pretend to channel Barry on this.

From stephen at xemacs.org  Sun Mar 18 09:52:59 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 18 Mar 2012 17:52:59 +0900
Subject: [Mailman-Developers] Grackle archive framework
In-Reply-To: <CAOb12VXO0OnhO4SZS4_a40o9F8yvHcKVeuNwTgz0pp+4tHcs7g@mail.gmail.com>
References: <CAOb12VV0XQnxew8yZaRdZzoBFyJ1RSdOjVaB7yJCO0NVg9oRUA@mail.gmail.com>
	<20120216142516.69c8fbc3@resist.wooz.org>
	<CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>
	<20120317185454.14c38939@limelight.wooz.org>
	<CAOb12VXO0OnhO4SZS4_a40o9F8yvHcKVeuNwTgz0pp+4tHcs7g@mail.gmail.com>
Message-ID: <CAL_0O18Ka86JH_m5kt+UJ8rs_N6LR7v4xqciVabj2UBvHDvWDQ@mail.gmail.com>

On Sun, Mar 18, 2012 at 2:25 PM, Aamir Khan <syst3m.w0rm at gmail.com> wrote:

> As for searching the archive, there are solutions like Elastic Search,
> Solr, lucene. Can we use one of them to search directly through the maildir.

Not quickly.  Many archives will have thousands of messages, some will have
hundreds of thousands.  There's no reasonable way to avoid indexes when
you've got more than "dozens" of files.  The stats alone will kill performance.

If you want a full-text solution, you're going to have to use a lot of
disk space
(typically as much as the compressed archives themselves, and for some
databases, more).

Also, I don't really see why a few hours' delay for indexing recent messages
would be a problem.

From stephen at xemacs.org  Sun Mar 18 11:28:44 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 18 Mar 2012 19:28:44 +0900
Subject: [Mailman-Developers] Thoughts on processing for pre-approved
	messages
In-Reply-To: <4F637B32.100@msapiro.net>
References: <4F637B32.100@msapiro.net>
Message-ID: <CAL_0O18OpsM_O+eBYp2z3uPPPONkpfTYJVKN=-2es0AYdVHvug@mail.gmail.com>

On Sat, Mar 17, 2012 at 2:41 AM, Mark Sapiro <mark at msapiro.net> wrote:

> I've gone around a bit on this and I've concluded this is analogous to
> the list poster password I implemented for 2.1. Presumably we don't
> want to allow this password to be used to authenticate to the web ui.

Right.

> We may want to allow it for authentication for certain email commands.
> I'm not sure about that one.

This is a list policy thing.  I wouldn't allow it, but then I don't plan to use
X-Approve either.


> Now I see some issues with what rules/approved.py does. It checks for
> the header and validates the password. This is good. It also removes
> any header or body lines containing the pseudo-header from the
> message. Architecturally, this latter operation belongs in the
> pipeline, not in a chain rule.

Strictly speaking, yes, but the whole idea of Approved: is unclean enough
that I don't really have a problem with allowing a chain rule to remove the
Approved: header.  But maybe there should be a pipeline Handler that
removes all Approved headers and pseudo-headers, regardless of whether
it would actually work on that list.

> we need a mlist.check_approved(msg, clean=True|False) method to do the
> heavy lifting.

I don't know about that.  Having both one or more Handlers and a special
seems like overkill, especially since really one checks the header and the
other deletes, completely different functionality.  Wouldn't it be
better to have
a class variable Mlist.approval_headers = ["Approve", "X-Approve"] and have

    for h in mlist.approval_headers:
        if msg[h] == mlist.moderator_password:
            return True
    return False

for the chain rule and

    for h in mlist.approval_headers:
        del msg[h]

in a RemoveApprovalHeaders.py pipeline handler?


> Unfortunately, this adds complexity and potential for
> security lapses if the rule hits but the pipeline doesn't remove the
> authentication.

Realistically, I don't think that's a problem.  I think that more likely
the problem will be that people will misspell the header, or use it in
list that doesn't support approval-by-header, or grab an incorrect
password out of an old message, or whatever.

From mark at msapiro.net  Sun Mar 18 18:59:32 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 18 Mar 2012 10:59:32 -0700
Subject: [Mailman-Developers] Thoughts on processing for pre-approved
 messages
In-Reply-To: <CAL_0O18OpsM_O+eBYp2z3uPPPONkpfTYJVKN=-2es0AYdVHvug@mail.gmail.com>
References: <4F637B32.100@msapiro.net>
	<CAL_0O18OpsM_O+eBYp2z3uPPPONkpfTYJVKN=-2es0AYdVHvug@mail.gmail.com>
Message-ID: <4F662284.6020504@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/18/2012 3:28 AM, Stephen J. Turnbull wrote:
> 
> ...  Having both one or more Handlers and a special seems like
> overkill, especially since really one checks the header and the 
> other deletes, completely different functionality.  Wouldn't it be 
> better to have a class variable Mlist.approval_headers =
> ["Approve", "X-Approve"] and have
> 
> for h in mlist.approval_headers: if msg[h] ==
> mlist.moderator_password: return True return False
> 
> for the chain rule and
> 
> for h in mlist.approval_headers: del msg[h]
> 
> in a RemoveApprovalHeaders.py pipeline handler?


If that were all that was required, that would be fine. The problem is
that we allow approval via a pseudo-header as the first non-blank body
line in the first text/plain part of the message, and we have to look
for it there and if found, not only remove it from that part, but also
from any alternative parts in which it might appear.

It's the removal of this pseudo-header from text/html alternatives
that is the hard part. See the comment thread at
<https://bugs.launchpad.net/mailman/+bug/266220>.


> ...  I think that more likely the problem will be that people will
> misspell the header, or use it in list that doesn't support
> approval-by-header, or grab an incorrect password out of an old
> message, or whatever.


Incorrect password is not an issue because we remove it anyway. The
other things *should* not be a problem because in theory the poster
wouldn't use the header if it weren't required, and in that case, the
post will be held since it isn't pre-approved. Of course in practice,
held posts get approved even if they might leak a password and users
do all sorts of things that don't make sense :(

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPZiKDVVuXXpU7hpMRAnmWAKD8z234ZKDZGFkAah8jiVW4/Zmd1wCgrtF8
tzWfzmXSJ1uycAo3yeMLpQA=
=08Vm
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Mon Mar 19 02:32:37 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 19 Mar 2012 10:32:37 +0900
Subject: [Mailman-Developers] Thoughts on processing for pre-approved
	messages
In-Reply-To: <4F662284.6020504@msapiro.net>
References: <4F637B32.100@msapiro.net>
	<CAL_0O18OpsM_O+eBYp2z3uPPPONkpfTYJVKN=-2es0AYdVHvug@mail.gmail.com>
	<4F662284.6020504@msapiro.net>
Message-ID: <CAL_0O1-R5qr+jDpWbp0G+97=KqEEhMZyrVfHvxPau2sQaVPf5Q@mail.gmail.com>

On Mon, Mar 19, 2012 at 2:59 AM, Mark Sapiro <mark at msapiro.net> wrote:

> If that were all that was required, that would be fine. The problem is
> that we allow approval via a pseudo-header as the first non-blank body
> line in the first text/plain part of the message, and we have to look
> for it there and if found, not only remove it from that part, but also
> from any alternative parts in which it might appear.
>
> It's the removal of this pseudo-header from text/html alternatives
> that is the hard part. See the comment thread at
> <https://bugs.launchpad.net/mailman/+bug/266220>.

OK, will do.

We really need a better way of doing this.  Something like requiring that
all parts for which approval is requested be signed by an authorized
private key, and unsigned parts be stripped.  Of course that will leave
most people out in the cold ....

> Incorrect password is not an issue because we remove it anyway.

That's true, assuming you do find it.  The real problem is whether you're
trying to find it:

> The other things *should* not be a problem because in theory the poster
> wouldn't use the header if it weren't required, and in that case, the
> post will be held since it isn't pre-approved. Of course in practice,
> held posts get approved even if they might leak a password and users
> do all sorts of things that don't make sense :(

Precisely.  Most people use Mailman *because* they have no idea what
makes sense.  That's really the most important point about automation.
It empowers people to accomplish tasks that they can't do on their own.

This requires them to trust the automation, of course, and that's often
not a great idea.  But "published source" helps.

From barry at list.org  Mon Mar 19 12:25:37 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 19 Mar 2012 07:25:37 -0400
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F652185.6010704@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
Message-ID: <20120319072537.0205c669@limelight.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mar 17, 2012, at 04:43 PM, Mark Sapiro wrote:

>Next step for me may be to learn more about how the unittests fit
>within their framework so I can create some.

It's *relatively* simple.  Essentially all unittests live in a test_foo.py
module inside a tests/ directory (which has an __init__.py so it's a
package).  I generally name unittest.TestCase subclasses as TestFoo and
individual tests inside there as test_foo() methods.  There are lots of
examples spread throughout.  It's only a little extra work if you have to
create a new tests/ subdirectory or test_foo.py module, but again, it should
be pretty straightforward.

These all get auto-discovered by the zope.testing framework, so there's
nothing else necessary to hook it all up.  The one other tricky thing is the
layers, which are a zope.testing mechanism to share more generic resources
among a suite of tests.  E.g. if you need the rest server to be started, you'd
use the RESTLayer (see mailman.testing.layers for what's currently defined).
To enable a layer, you just need to set the `layer` attribute of the TestFoo
class.  Almost all the tests will require at least the ConfigLayer since that
brings up the Zope component architecture, connfiguration system, etc.

zope.testing is a bit weird here because the normal rules of subclasses don't
actually apply.  E.g. the LMTPLayer derives from ConfigLayer which derives
from MockAndMonkeyLayer.  All the appropriate setUp()s get called by
zope.testing so you don't need to up-call explicitly in the layer class.  Yes,
this kind of sucks since it's magical, and it's one reason why eventually I'd
like to switch to something like testresources and a more sane testing
framework, but that's a lot of effort for little immediate value.

Note that doctests are all set up in test_documentation.py so they're not
really all that special.

>Also, I need to figure out a better development platform for Windows
>boxes. I had a perfect opportunity to scrap Windows all together when
>I had to recover from a hard drive crash on my main development box
>last year, but the dice fell the wrong way on that one.

There are lots of options here.  As mentioned, virtualbox should be a good
option, and you can probably use something like wubi to create an Ubuntu
desktop running along side Windows.  Of course, all the Linuxes should give
you a way to dual-boot your Windows machine if you're so inclined.  You may
even be able to boot off a USB drive or stick, though that will be slower.
Commercial options such as VMware are also a possibility, though of course you
should try the free options first. :)

>Maybe I can organize a sprint at the next PyCon - Migrating to Linux
>and killing Windows one PC at a time.

Definitely. :)

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPZxexAAoJEBJutWOnSwa/jlQQAKqzGaL5Vrnm5vS8+NSlN+LH
gY/Gyh/aT8F4V6IYd3Hn47kPMtdMPv6m+FNhSTOGkwf1EU1UtPgNvkcYUNuVsHBe
A9Bh04DDk0t5S1WOdcKBSdkwt65YR3yNkvsiCZQpOXD4xDF4EDlSRwNTjtGk6ze7
84xBUL5DXJiO1L5OxBsZusYlR4vpO80AwCszil3uon9oDQIxsHuXvPfVwjJM8CfN
hFf3Rq7LePLbOO0uFNLxsDxMyRZx0wrN/vg+2H81bnLNdheaqlmRjoZn2TkFZmTb
eYN+XeFW9l2jlGgYfQAm8R5e+mNhE+a3HG7LwO2IyYn8JzR+YTFQeiR91XdOFYrt
OPfMrXbUaRAb6QEwwWJY2HmbqIiihgFOPtmSBSRcIoiU/cWjC6LbajZN8QV24xhq
yTrbkBxZBTGPPQ7tgd05bb/PYlqdWCRoXeL8zlbcDK98MFzPgfBMfmHqWObPd+8E
q49pDoeDUlhW+SmhfTOqM3zQvuolIu6WYDTcTeIWYLzMsjT3pDJ6R1NIw4jNGmtl
TqLYL+WuUzBXyNfGD234C2VnJscVyJLFduew2pig6dFG0MX9gAN/zTI3i8wZDlUC
xDKDagCZ7uSNzjVEDQLzoZmrs3EzuPvCY5h4kzlVObUiKBvg8ALPEV8MJS6M8QDj
IeBbG8Iniz01AoBaixZ1
=rxit
-----END PGP SIGNATURE-----

From andrea.crotti.0 at gmail.com  Mon Mar 19 13:03:29 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 19 Mar 2012 12:03:29 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120319072537.0205c669@limelight.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
Message-ID: <4F672091.1050904@gmail.com>

On 03/19/2012 11:25 AM, Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mar 17, 2012, at 04:43 PM, Mark Sapiro wrote:
>
>> Next step for me may be to learn more about how the unittests fit
>> within their framework so I can create some.
> It's *relatively* simple.  Essentially all unittests live in a test_foo.py
> module inside a tests/ directory (which has an __init__.py so it's a
> package).  I generally name unittest.TestCase subclasses as TestFoo and
> individual tests inside there as test_foo() methods.  There are lots of
> examples spread throughout.  It's only a little extra work if you have to
> create a new tests/ subdirectory or test_foo.py module, but again, it should
> be pretty straightforward.
>
> These all get auto-discovered by the zope.testing framework, so there's
> nothing else necessary to hook it all up.  The one other tricky thing is the
> layers, which are a zope.testing mechanism to share more generic resources
> among a suite of tests.  E.g. if you need the rest server to be started, you'd
> use the RESTLayer (see mailman.testing.layers for what's currently defined).
> To enable a layer, you just need to set the `layer` attribute of the TestFoo
> class.  Almost all the tests will require at least the ConfigLayer since that
> brings up the Zope component architecture, connfiguration system, etc.
>
> zope.testing is a bit weird here because the normal rules of subclasses don't
> actually apply.  E.g. the LMTPLayer derives from ConfigLayer which derives
> from MockAndMonkeyLayer.  All the appropriate setUp()s get called by
> zope.testing so you don't need to up-call explicitly in the layer class.  Yes,
> this kind of sucks since it's magical, and it's one reason why eventually I'd
> like to switch to something like testresources and a more sane testing
> framework, but that's a lot of effort for little immediate value.
>
> Note that doctests are all set up in test_documentation.py so they're not
> really all that special.
>
>

Just as a suggestion, it would be nice to have a few lines in the 
documentation about this, something
like you just explained would be already quite good, since it's not so 
clear by just looking at the code..

Cheers,
Andrea


From adam-mailman at amyl.org.uk  Mon Mar 19 12:50:49 2012
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Mon, 19 Mar 2012 11:50:49 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120319072537.0205c669@limelight.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
Message-ID: <20120319115049.GF4083@hendricks.amyl.org.uk>

On Mon, Mar 19, 2012 at 07:25:37AM -0400, Barry Warsaw wrote:
> >Also, I need to figure out a better development platform for Windows
> >boxes. I had a perfect opportunity to scrap Windows all together when
> >I had to recover from a hard drive crash on my main development box
> >last year, but the dice fell the wrong way on that one.
> 
> There are lots of options here.  As mentioned, virtualbox should be a good
> option, and you can probably use something like wubi to create an Ubuntu
> desktop running along side Windows. 

    http://xkcd.com/424/

springs to mind.

(I'm aware a fair few people are moving away from Ubuntu, in favor of
Mint <http://linuxmint.com/>).

> >Maybe I can organize a sprint at the next PyCon - Migrating to Linux
> >and killing Windows one PC at a time.

With a python script? ;o)

(a former friend & colleague, Chris Lightfoot[1] wrote evil.c one day; I
mirror it at http://hendricks.amyl.org.uk/~adam/tmp/evil.c-txt --
to Debianize a FBSD box. Console server *highly* recommended. It
worked the few times we used it)


[1] http://www.ex-parrot.com/~chris/wwwitter/20070305-chris_lightfoot_1978-2007.html

-- 
War is Peace   Freedom is Slavery   Ignorance is Strength
    1984

From barry at list.org  Mon Mar 19 13:27:19 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 19 Mar 2012 08:27:19 -0400
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F672091.1050904@gmail.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F672091.1050904@gmail.com>
Message-ID: <20120319082719.0eaa11e2@resist.wooz.org>

On Mar 19, 2012, at 12:03 PM, Andrea Crotti wrote:

>Just as a suggestion, it would be nice to have a few lines in the
>documentation about this, something like you just explained would be already
>quite good, since it's not so clear by just looking at the code..

Care to adapt my post into a merge proposal? :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120319/fe0e3c7e/attachment.pgp>

From andrea.crotti.0 at gmail.com  Mon Mar 19 14:50:21 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 19 Mar 2012 13:50:21 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120319082719.0eaa11e2@resist.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F672091.1050904@gmail.com>
	<20120319082719.0eaa11e2@resist.wooz.org>
Message-ID: <4F67399D.7080309@gmail.com>

On 03/19/2012 12:27 PM, Barry Warsaw wrote:
> On Mar 19, 2012, at 12:03 PM, Andrea Crotti wrote:
>
>> Just as a suggestion, it would be nice to have a few lines in the
>> documentation about this, something like you just explained would be already
>> quite good, since it's not so clear by just looking at the code..
> Care to adapt my post into a merge proposal? :)
>
> -Barry

Yes sure I will do that ASAP..

From a.badger at gmail.com  Mon Mar 19 20:32:45 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 19 Mar 2012 12:32:45 -0700
Subject: [Mailman-Developers] Grackle archive framework
In-Reply-To: <CAOb12VXO0OnhO4SZS4_a40o9F8yvHcKVeuNwTgz0pp+4tHcs7g@mail.gmail.com>
References: <CAOb12VV0XQnxew8yZaRdZzoBFyJ1RSdOjVaB7yJCO0NVg9oRUA@mail.gmail.com>
	<20120216142516.69c8fbc3@resist.wooz.org>
	<CAOb12VW_=qJYwSom6y78H8jX_Lj+bVu5S1=fU25f-NThXC4z1w@mail.gmail.com>
	<20120317185454.14c38939@limelight.wooz.org>
	<CAOb12VXO0OnhO4SZS4_a40o9F8yvHcKVeuNwTgz0pp+4tHcs7g@mail.gmail.com>
Message-ID: <20120319193244.GI11151@unaka.lan>

On Sun, Mar 18, 2012 at 10:55:19AM +0530, Aamir Khan wrote:
> On Sun, Mar 18, 2012 at 4:24 AM, Barry Warsaw <barry at list.org> wrote:
> 
> > On Mar 18, 2012, at 12:23 AM, Aamir Khan wrote:
> >
> > >On Fri, Feb 17, 2012 at 12:55 AM, Barry Warsaw <barry at list.org> wrote:
> > >> On IRC, we talked about a storm + Python mailbox library based backend,
> > >> with a
> > >> REST+JSON wsgi based application vending the data.  This would allow us
> > to
> > >> integrate fairly easily with MM3 I think, and would possibly better
> > enable
> > >> some of the archiver work being done by Terri and others.
> > >>
> > >
> > >I understand that we will store the messages in .mbox format. But I don't
> > >understand why do we need to use storm for the archiving purpose.
> >
> > I meant to say "maildir".  Please let's not use mbox format!  It's way too
> > easy to corrupt the file, as we did with a bug once in MM2.1, and we've
> > paid
> > the price ever since.
> >
> 
> I read the difference between maildir and mbox format and it clearly states
> that mbox is prone to corruption while maildir is not. Also there are more
> advantages using maildir in a way that there is no file locking problem.
> But since we will be storing each mail in a separate file, searching
> through them will not as fast enough. Using database alone also have
> problems like, it will use more hard disk, more CPU cycles will be consumed.
> 
> So, if we can store the messages in maildir format with a copy of it it
> database. we can serve the searching request using database query which
> will powered by full-text search engine. But then there will be problems of
> synchronization between the maildir messages and  messages stored in
> database. What are your thoughts about it ?
> 
> As for searching the archive, there are solutions like Elastic Search,
> Solr, lucene. Can we use one of them to search directly through the maildir.
> 
Note that a few of us have been playing with a searching-archiver.  An
initial prototype used notmuch.  We looked into using raw xapian at pycon.
And now, one of our developers (pingou on IRC) has pushed out a prototype
that uses mongodb for the backend.

You can take a look at our development copy here:

http://mm3test.fedoraproject.org/2/list/devel at fp.o

I'll be working on splitting out a tested copy from an in-development copy
later today.  That way we won't be creating web pages with tracebacks all
the time :-)

Code for this is available in the hyperkitty mongodb branch:

bzr branch bzr://bzr.fedorahosted.org/bzr/hyperkitty/mongodb

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120319/0472e947/attachment.pgp>

From mark at msapiro.net  Mon Mar 19 22:14:15 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 19 Mar 2012 14:14:15 -0700
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <20120319072537.0205c669@limelight.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
Message-ID: <4F67A1A7.6040401@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/19/2012 4:25 AM, Barry Warsaw wrote:
> 
> There are lots of options here.  As mentioned, virtualbox should be
> a good option, and you can probably use something like wubi to
> create an Ubuntu desktop running along side Windows.


Thanks to all for the advice. I have some learning to do.

I actually have VirtualBox installed and for the sprint I had a
Vagrant VM set up running the basic
http://files.vagrantup.com/lucid32.box. I had set up a virtualenv on
this box with Sphinx installed for the Sphinx tutorial at PyCon, and
this worked really well.

When I got to the Mailman sprint, I tried to install MM 3 on this
Vagrant VM, and I ran into some error with buildout trying to compile
some package and failing with a missing Python.h file.

I ran 'sudo apt-get install python-dev' on the VM which I thought
would fix it, and the install seemed to run OK, but I still had no
Python.h.

At that point, I gave up and went to a virtualenv on my production server.

At this point, I don't know whether the best approach is look for a
more complete development box for Vagrant or figure out how to
provision the basic Vagrant box with what I need or forget Vagrant and
install directly in VirtualBox or go with a dual-boot.

Anyway, it's going to be interesting to figure this out.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFPZ6GnVVuXXpU7hpMRAlwwAJ91EQ7k4TtOLBvyexmrmyspzJZ8RACg3iFQ
fdgRt+ylQxrcuoL0d3W+VMY=
=lP82
-----END PGP SIGNATURE-----

From andrea.crotti.0 at gmail.com  Mon Mar 19 22:39:17 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 19 Mar 2012 21:39:17 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F67A1A7.6040401@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
Message-ID: <4F67A785.6060204@gmail.com>

On 03/19/2012 09:14 PM, Mark Sapiro wrote:
>
> Thanks to all for the advice. I have some learning to do.
>
> I actually have VirtualBox installed and for the sprint I had a
> Vagrant VM set up running the basic
> http://files.vagrantup.com/lucid32.box. I had set up a virtualenv on
> this box with Sphinx installed for the Sphinx tutorial at PyCon, and
> this worked really well.
>
> When I got to the Mailman sprint, I tried to install MM 3 on this
> Vagrant VM, and I ran into some error with buildout trying to compile
> some package and failing with a missing Python.h file.
>
> I ran 'sudo apt-get install python-dev' on the VM which I thought
> would fix it, and the install seemed to run OK, but I still had no
> Python.h.
>
> At that point, I gave up and went to a virtualenv on my production server.
>
> At this point, I don't know whether the best approach is look for a
> more complete development box for Vagrant or figure out how to
> provision the basic Vagrant box with what I need or forget Vagrant and
> install directly in VirtualBox or go with a dual-boot.
>
> Anyway, it's going to be interesting to figure this out.
>


Well but why using Vagrant?
Vagrant is great to create VMS for automatic testing, but if you want to 
create your own
VM with all your things that you need I don't see how it can help, just 
install a normal
Ubuntu/whatever on Virtualbox and you're fine..

And another possible advice is to always copy the errors you get, also 
because most of the times
you can get the answer you want simply by a quick google search ;)

From Chris.Clark at actian.com  Mon Mar 19 22:44:32 2012
From: Chris.Clark at actian.com (Chris Clark)
Date: Mon, 19 Mar 2012 14:44:32 -0700
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F67A785.6060204@gmail.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67A785.6060204@gmail.com>
Message-ID: <4F67A8C0.4090304@actian.com>

On Monday 2012-03-19 14:40 (-0700), Andrea Crotti 
<andrea.crotti.0 at gmail.com> wrote:
> Well but why using Vagrant?
> Vagrant is great to create VMS for automatic testing, but if you want 
> to create your own
> VM with all your things that you need I don't see how it can help, 
> just install a normal
> Ubuntu/whatever on Virtualbox and you're fine..

I'd recommend this too. (Vagrant for repeatable deployments, you only 
need one).

If you like Ubuntu, Ubuntu Server (an LTS version) is well worth using 
for this sort of thing as it is already headless, no desktop (or though 
you can add one if you want).

Chris


From barry at list.org  Mon Mar 19 22:47:48 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 19 Mar 2012 17:47:48 -0400
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F67A1A7.6040401@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
Message-ID: <20120319174748.56d8bad0@resist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mar 19, 2012, at 02:14 PM, Mark Sapiro wrote:

>I ran 'sudo apt-get install python-dev' on the VM which I thought
>would fix it, and the install seemed to run OK, but I still had no
>Python.h.

Hmm, I just tried this in a Lucid chroot and it worked for me. :/

I do get test failures (could be 2.6 related) but everything built.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPZ6mFAAoJEBJutWOnSwa/5IIP/3bo0dOX/ESg4wDbtd//sjcr
9AHwT7X3oOUIB9H8IAqRkSFNTIZDoxTtLrv7BzIHLgfIAkS9KaKcRSK3IGlulPrG
6KtCf93nVbtd8KdRYDxT2TmWhoR377g9DDnGDztcf6N39HiSVrPNzxLx2oSMrfYh
cvLhQnGnI7xOloVox6uEvEB7fU1DQaLJe6G4obZxzr0YZGViZGv1u4h1Qi0dgPgO
7Av1cne29t7+4iyNbgoo8nvCmSBcE4Lbmg3e+mHr25BMpKUKuM0sce323RN3Pp/+
5GZOtFuiWKYB/GHmm0OpIRCUCMX1oPf2SyVw94+MYW32wspDbUpOBevgtGPbFmQx
WtKm1l6ps2TGX+q5WatNVemtmoZWVLx7N6CfxdcyZ7kdIvnGkxVqylq7o5RUWUQM
83rqo4EEDPZjnF7Aos7RgdSUAbdh99Rus4/8VoCJgg4sTbMjFFcH/PRiYeiMR+GK
GJtFiZilYjiXUnCZ6jye3s6mBsy/YHtUd3ytYrjUtritVgMcMuPF0EwRTwb04OIN
TWmE5BNvlgF8mn0U1UA3+V5A42GqjnK7PajZ9VpTwyymU65QgK7PSwIYyXNzATQb
wHHokKct8sE4eNWt9Bs4Ai6MlMJKLoAFaOJvJQtZ2r0OBpuBcNomHb0c2yddlGSr
Yj04lLFc/Sp3FFko9EbU
=Ib4D
-----END PGP SIGNATURE-----

From richard at NFSNet.org  Mon Mar 19 23:41:44 2012
From: richard at NFSNet.org (Richard Wackerbarth)
Date: Mon, 19 Mar 2012 17:41:44 -0500
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
	scrubbing in Mailman 3
In-Reply-To: <20120319174748.56d8bad0@resist.wooz.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
	<20120319174748.56d8bad0@resist.wooz.org>
Message-ID: <BAB1E900-DB0E-4EDA-9315-810B0DB4B725@NFSNet.org>

I, too, am attempting to get MM3 running on my new laptop (Mac OSX 10.7).
Because of the way Xcode 4.3 and Python are set up, compiling the .c extensions in storm is failing.

I need to figure out where I can tell setup.py to add an additional "include" path when it calls the  c compiler.

Anyone know how?

Richard

On Mar 19, 2012, at 4:47 PM, Barry Warsaw wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Mar 19, 2012, at 02:14 PM, Mark Sapiro wrote:
> 
>> I ran 'sudo apt-get install python-dev' on the VM which I thought
>> would fix it, and the install seemed to run OK, but I still had no
>> Python.h.
> 
> Hmm, I just tried this in a Lucid chroot and it worked for me. :/
> 
> I do get test failures (could be 2.6 related) but everything built.
> 
> - -Barry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJPZ6mFAAoJEBJutWOnSwa/5IIP/3bo0dOX/ESg4wDbtd//sjcr
> 9AHwT7X3oOUIB9H8IAqRkSFNTIZDoxTtLrv7BzIHLgfIAkS9KaKcRSK3IGlulPrG
> 6KtCf93nVbtd8KdRYDxT2TmWhoR377g9DDnGDztcf6N39HiSVrPNzxLx2oSMrfYh
> cvLhQnGnI7xOloVox6uEvEB7fU1DQaLJe6G4obZxzr0YZGViZGv1u4h1Qi0dgPgO
> 7Av1cne29t7+4iyNbgoo8nvCmSBcE4Lbmg3e+mHr25BMpKUKuM0sce323RN3Pp/+
> 5GZOtFuiWKYB/GHmm0OpIRCUCMX1oPf2SyVw94+MYW32wspDbUpOBevgtGPbFmQx
> WtKm1l6ps2TGX+q5WatNVemtmoZWVLx7N6CfxdcyZ7kdIvnGkxVqylq7o5RUWUQM
> 83rqo4EEDPZjnF7Aos7RgdSUAbdh99Rus4/8VoCJgg4sTbMjFFcH/PRiYeiMR+GK
> GJtFiZilYjiXUnCZ6jye3s6mBsy/YHtUd3ytYrjUtritVgMcMuPF0EwRTwb04OIN
> TWmE5BNvlgF8mn0U1UA3+V5A42GqjnK7PajZ9VpTwyymU65QgK7PSwIYyXNzATQb
> wHHokKct8sE4eNWt9Bs4Ai6MlMJKLoAFaOJvJQtZ2r0OBpuBcNomHb0c2yddlGSr
> Yj04lLFc/Sp3FFko9EbU
> =Ib4D
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9


From terri at zone12.com  Tue Mar 20 00:02:47 2012
From: terri at zone12.com (Terri Oda)
Date: Mon, 19 Mar 2012 17:02:47 -0600
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67A1A7.6040401@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
Message-ID: <4F67BB17.3070007@zone12.com>

On 03/19/2012 03:14 PM, Mark Sapiro wrote:
> At this point, I don't know whether the best approach is look for a
> more complete development box for Vagrant or figure out how to
> provision the basic Vagrant box with what I need or forget Vagrant and
> install directly in VirtualBox or go with a dual-boot.
>
> Anyway, it's going to be interesting to figure this out.

Incidentally, how much interest would there be in having a 
Mailman-developer VM (say, for VirtualBox) around and easy to download? 
  Some modern distro, appropriate dev tools, and a checkout of 
moderately recent code, maybe even ready to run with instructions on the 
desktop or something?  It seems like it might be a nice thing to hand 
out to prospective GSoC students as well as Mark. ;)  The Systers folk 
made one a few years ago for 2.1 dev and maybe it's time for an updated 
version?

  Terri

From mark at msapiro.net  Tue Mar 20 02:17:38 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 19 Mar 2012 18:17:38 -0700
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67BB17.3070007@zone12.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67BB17.3070007@zone12.com>
Message-ID: <4F67DAB2.8010700@msapiro.net>

On 3/19/2012 4:02 PM, Terri Oda wrote:
> 
> Incidentally, how much interest would there be in having a
> Mailman-developer VM (say, for VirtualBox) around and easy to download?
>  Some modern distro, appropriate dev tools, and a checkout of moderately
> recent code, maybe even ready to run with instructions on the desktop or
> something?  It seems like it might be a nice thing to hand out to
> prospective GSoC students as well as Mark. ;)


I think it would be great. I'm not sure how fast I will progress with
this, but I may be the one to make it. If it were available right now, I
would certainly use it.

I'm currently thinking about VirtualBox vs. dual boot. I'm used to
working with Cygwin command windows on my Windows desktop. There are
various issues with Cygwin, both itself and WRT MM 3, so I need to move
away from that. VirtualBox would allow me to continue to work in a
hybrid environment with some Windows applications and some Unix like
applications running together, but dual boot might avoid potential
hardware interface issues and would motivate me to move completely away
from Windows (although I would probably still need access to Windows to
diagnose user problems with the web site I admin).

Of course, I could always do both. The two machines I would do this on
both have two 200GB+ hard drives with lots of available space so disc is
not a problem. My travel computer has 8GB of ram and a dual-core 64 bit
CPU, so that's plenty I'm sure. My main, at home computer is over 10
years old and has only 2GB of ram and a Pentium 4 CPU, but I think even
it would be OK.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From barry at list.org  Tue Mar 20 04:10:06 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 19 Mar 2012 23:10:06 -0400
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67BB17.3070007@zone12.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67BB17.3070007@zone12.com>
Message-ID: <20120319231006.6c480a34@resist.wooz.org>

On Mar 19, 2012, at 05:02 PM, Terri Oda wrote:

>On 03/19/2012 03:14 PM, Mark Sapiro wrote:
>> At this point, I don't know whether the best approach is look for a
>> more complete development box for Vagrant or figure out how to
>> provision the basic Vagrant box with what I need or forget Vagrant and
>> install directly in VirtualBox or go with a dual-boot.
>>
>> Anyway, it's going to be interesting to figure this out.
>
>Incidentally, how much interest would there be in having a Mailman-developer
>VM (say, for VirtualBox) around and easy to download?  Some modern distro,
>appropriate dev tools, and a checkout of moderately recent code, maybe even
>ready to run with instructions on the desktop or something?  It seems like it
>might be a nice thing to hand out to prospective GSoC students as well as
>Mark. ;) The Systers folk made one a few years ago for 2.1 dev and maybe it's
>time for an updated version?

+1 is an understatement. :)

-Barry

From barry at list.org  Tue Mar 20 04:12:03 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 19 Mar 2012 23:12:03 -0400
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67DAB2.8010700@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67BB17.3070007@zone12.com>
	<4F67DAB2.8010700@msapiro.net>
Message-ID: <20120319231203.2e54c8be@resist.wooz.org>

On Mar 19, 2012, at 06:17 PM, Mark Sapiro wrote:

>I'm currently thinking about VirtualBox vs. dual boot. I'm used to
>working with Cygwin command windows on my Windows desktop. There are
>various issues with Cygwin, both itself and WRT MM 3, so I need to move
>away from that. VirtualBox would allow me to continue to work in a
>hybrid environment with some Windows applications and some Unix like
>applications running together, but dual boot might avoid potential
>hardware interface issues and would motivate me to move completely away
>from Windows (although I would probably still need access to Windows to
>diagnose user problems with the web site I admin).

From a technical standpoint, you can run Windows in a virtual machine hosted
on Linux. :)

-Barry

From dgc at uchicago.edu  Tue Mar 20 04:16:20 2012
From: dgc at uchicago.edu (David Champion)
Date: Mon, 19 Mar 2012 22:16:20 -0500
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67BB17.3070007@zone12.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67BB17.3070007@zone12.com>
Message-ID: <20120320031620.GN10848@scurvy.bikeshed.us>

* On 19 Mar 2012, Terri Oda wrote: 
> 
> Incidentally, how much interest would there be in having a Mailman-developer
> VM (say, for VirtualBox) around and easy to download?  Some modern distro,

I'm not very active around here anymore, but I'll toss this to the
table: maybe a public ec2 AMI?  A sponsoring foundation could even host
an account with "IAM" (Amazon IDM) to run them under and pay for the AMI
storage.

-- 
David Champion ? dgc at uchicago.edu ? IT Services ? University of Chicago

From barry at list.org  Tue Mar 20 15:36:24 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 20 Mar 2012 10:36:24 -0400
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <BAB1E900-DB0E-4EDA-9315-810B0DB4B725@NFSNet.org>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
	<20120319174748.56d8bad0@resist.wooz.org>
	<BAB1E900-DB0E-4EDA-9315-810B0DB4B725@NFSNet.org>
Message-ID: <20120320103624.60b79fbe@resist.wooz.org>

On Mar 19, 2012, at 05:41 PM, Richard Wackerbarth wrote:

>I, too, am attempting to get MM3 running on my new laptop (Mac OSX 10.7).
>Because of the way Xcode 4.3 and Python are set up, compiling the .c
>extensions in storm is failing.
>
>I need to figure out where I can tell setup.py to add an additional "include"
>path when it calls the c compiler.
>
>Anyone know how?

I've never done it, but I found this.  Hopefully that helps.

http://www.buildout.org/docs/tutorial.html#custom-egg-building

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120320/ff9b95ed/attachment.pgp>

From andrea.crotti.0 at gmail.com  Tue Mar 20 15:40:08 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Tue, 20 Mar 2012 14:40:08 +0000
Subject: [Mailman-Developers] VM for Mailman development
In-Reply-To: <4F67BB17.3070007@zone12.com>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net> <4F67BB17.3070007@zone12.com>
Message-ID: <4F6896C8.1020408@gmail.com>

On 03/19/2012 11:02 PM, Terri Oda wrote:
> On 03/19/2012 03:14 PM, Mark Sapiro wrote:
>> At this point, I don't know whether the best approach is look for a
>> more complete development box for Vagrant or figure out how to
>> provision the basic Vagrant box with what I need or forget Vagrant and
>> install directly in VirtualBox or go with a dual-boot.
>>
>> Anyway, it's going to be interesting to figure this out.
>
> Incidentally, how much interest would there be in having a 
> Mailman-developer VM (say, for VirtualBox) around and easy to 
> download?  Some modern distro, appropriate dev tools, and a checkout 
> of moderately recent code, maybe even ready to run with instructions 
> on the desktop or something?  It seems like it might be a nice thing 
> to hand out to prospective GSoC students as well as Mark. ;)  The 
> Systers folk made one a few years ago for 2.1 dev and maybe it's time 
> for an updated version?
>
>  Terri


That sounds like a good idea :)
In this case, maybe something declarative with puppet/vagrant might 
really be a very good idea, since
it's much easier to ship a configuration file and it has to be deployed 
/ updated easily...

From andrea.crotti.0 at gmail.com  Wed Mar 21 12:01:31 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Wed, 21 Mar 2012 11:01:31 +0000
Subject: [Mailman-Developers] Killing off Pipermail and the effects on
 scrubbing in Mailman 3
In-Reply-To: <4F67A1A7.6040401@msapiro.net>
References: <20120315224158.3afa4323@resist> <4F63742E.9010902@msapiro.net>
	<20120317130500.7b9e4584@resist.wooz.org>
	<4F652185.6010704@msapiro.net>
	<20120319072537.0205c669@limelight.wooz.org>
	<4F67A1A7.6040401@msapiro.net>
Message-ID: <4F69B50B.1070207@gmail.com>

On 03/19/2012 09:14 PM, Mark Sapiro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 3/19/2012 4:25 AM, Barry Warsaw wrote:
>> There are lots of options here.  As mentioned, virtualbox should be
>> a good option, and you can probably use something like wubi to
>> create an Ubuntu desktop running along side Windows.
>
> Thanks to all for the advice. I have some learning to do.
>
> I actually have VirtualBox installed and for the sprint I had a
> Vagrant VM set up running the basic
> http://files.vagrantup.com/lucid32.box. I had set up a virtualenv on
> this box with Sphinx installed for the Sphinx tutorial at PyCon, and
> this worked really well.
>
> When I got to the Mailman sprint, I tried to install MM 3 on this
> Vagrant VM, and I ran into some error with buildout trying to compile
> some package and failing with a missing Python.h file.
>
> I ran 'sudo apt-get install python-dev' on the VM which I thought
> would fix it, and the install seemed to run OK, but I still had no
> Python.h.
>
> At that point, I gave up and went to a virtualenv on my production server.
>
> At this point, I don't know whether the best approach is look for a
> more complete development box for Vagrant or figure out how to
> provision the basic Vagrant box with what I need or forget Vagrant and
> install directly in VirtualBox or go with a dual-boot.
>
> Anyway, it's going to be interesting to figure this out.
>
>

Since I was curious to see I created a vagrant VM with lucid and I only 
needed to install the following:

    To install (Lucid32):
    - python
    - python-dev
    - bzr
    - python-setuptools
    - gcc

To make everything work and be able to run buildout and bin/test in 
mailman bzr version.
So now I was thinking to transform this manual steps in a Vagrantfile, 
and we could use this
to ship for people that want to try, other things to do:

    Optional packages:
    - Gnome / XFCE / Other
    - vim

    To check/set:
    - launchpad login, possibly passing the authentication and the SSH
      key somehow to the vagrant file
    - dimension of the VM to make sure it's not too small

PS. I get 6 failures running the tests though, as
File "/home/vagrant/mailman/src/mailman/model/docs/users.rst", line 172, 
in users.rst
Failed example:
     user_2.preferred_address = anne
Differences (ndiff with -expected +actual):
       Traceback (most recent call last):
     - ...
     - UnverifiedAddressError: Anne Person <anne at example.com>
     +   File "/usr/lib/python2.6/doctest.py", line 1248, in __run
     +     compileflags, 1) in test.globs
     +   File "<doctest users.rst[41]>", line 1, in <module>
     +     user_2.preferred_address = anne
     +   File "/home/vagrant/mailman/src/mailman/model/user.py", line 
112, in preferred_address
     +     raise UnverifiedAddressError(address)
     + UnverifiedAddressError: <unprintable UnverifiedAddressError object>




From barry at list.org  Fri Mar 23 01:09:38 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 22 Mar 2012 20:09:38 -0400
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <4F6380DF.4000708@gmail.com>
References: <4F6380DF.4000708@gmail.com>
Message-ID: <20120322200938.04921f6b@resist.wooz.org>

On Mar 16, 2012, at 06:05 PM, Andrea Crotti wrote:

>https://bugs.launchpad.net/mailman/+bug/956889

This one got duped to 266684.  We have (almost) all the basics to make this
work in message headers/footers, but it's not plumbed through yet.  One
complication is this:

If we add something like $archive_url to the decoration interpolation
dictionary, what happens when we have multiple archivers that support
permalink() enabled?  Do we chose one at random (these are unordered)?  Do we
add a configuration variable to select a "primary" archiver for this?  Do we
allow something like $archive_url.prototype as an interpolation variable to
select e.g. the 'prototype' archiver?

This isn't much of a problem for the RFC 822 headers, because we can just add
multiple Archived-At headers.

>https://bugs.launchpad.net/mailman/+bug/956384

+1.  I followed up on the tracker issue.

Don't forget to tag Mailman 3 issues with the 'mailman3' tag!

>PS. ironically today they asked me for the first time in my life to check why
>Mailman was not working on a Linux server. The problem was that /var was
>full, but well knowing more about Mailman certainly helped :D

Yay!
-Barry

From barry at list.org  Fri Mar 23 01:10:42 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 22 Mar 2012 20:10:42 -0400
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <CAL_0O1-VQEvqN47aqpDO-yx+exbSXXCPLopEijExEDfbp48Xzg@mail.gmail.com>
References: <4F6380DF.4000708@gmail.com>
	<CAL_0O1-VQEvqN47aqpDO-yx+exbSXXCPLopEijExEDfbp48Xzg@mail.gmail.com>
Message-ID: <20120322201042.505bf67b@resist.wooz.org>

On Mar 18, 2012, at 04:36 PM, Stephen J. Turnbull wrote:

>On Sat, Mar 17, 2012 at 3:05 AM, Andrea Crotti
><andrea.crotti.0 at gmail.com> wrote:
>> Hi everyone,
>> I filed in two bugs today:
>> https://bugs.launchpad.net/mailman/+bug/956889
>> https://bugs.launchpad.net/mailman/+bug/956384
>
>These are both policy issues, I think they should be posted to the
>list as well as filed on Launchpad, or instead of in the case of
>continuous integration.  Once it's decided what to do about them, a
>specific issue should filed to track progress.
>
>IMO YMMV etc -- I don't pretend to channel Barry on this.

But you didn't do so badly! :)

-Barry

From stephen at xemacs.org  Fri Mar 23 01:48:52 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 23 Mar 2012 01:48:52 +0100
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <20120322200938.04921f6b@resist.wooz.org>
References: <4F6380DF.4000708@gmail.com>
	<20120322200938.04921f6b@resist.wooz.org>
Message-ID: <CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>

On Fri, Mar 23, 2012 at 1:09 AM, Barry Warsaw <barry at list.org> wrote:

> If we add something like $archive_url to the decoration interpolation
> dictionary, what happens when we have multiple archivers that support
> permalink() enabled? ?Do we chose one at random (these are unordered)?

-1

> Do we add a configuration variable to select a "primary" archiver for this?

+1

If there's *no* archiver configuration variable, we don't know where to
point to anyway for Gmane-like archivers (yes, I know, catering to Gmane
will give Brad hives, but some people like Gmane).  The local archive, if it
exists, may seem TOOWTDI, but it might not be the preferred one even if
it's the only one configured in Mailman (although that seems a lot less
likely than the case where somebody just grandfathers an existing Gmane
subscription as the archive URL of choice).

> Do we allow something like $archive_url.prototype as an interpolation
> variable to select e.g. the 'prototype' archiver?

-1

Too complex.  If people want alternative archives, they can go to
the list FAQ or the Archived-At headers.  If we go this way, we'd
better have a *really* good comment and a pre-existing entry in
the FAQ to save Mark some time. :-)

From andrea.crotti.0 at gmail.com  Fri Mar 23 10:13:01 2012
From: andrea.crotti.0 at gmail.com (andrea crotti)
Date: Fri, 23 Mar 2012 09:13:01 +0000
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>
References: <4F6380DF.4000708@gmail.com>
	<20120322200938.04921f6b@resist.wooz.org>
	<CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>
Message-ID: <CAF_E5JbNNQdN=4rPbY8e6UmBb=FVXgUs8SdAS2_Yn6ehipUqKA@mail.gmail.com>

My idea as a user would be to be able to select from my
web configuration page an option:

send_public_url_in_mail_footers: [
disabled,
gmane_url,
mailmanweb_url
]

And maybe it would be cool (if possible I have no idea) to add a mail
command that when I send

subject: public $mailing_list $id

I get back an email with this url.  Because maybe from one mailing list
I'm normally not interested in the url and I also want it in some cases.

Not sure I anyone else in the world would like this feature though :D

From stephen at xemacs.org  Fri Mar 23 11:45:26 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 23 Mar 2012 11:45:26 +0100
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <CAF_E5JbNNQdN=4rPbY8e6UmBb=FVXgUs8SdAS2_Yn6ehipUqKA@mail.gmail.com>
References: <4F6380DF.4000708@gmail.com>
	<20120322200938.04921f6b@resist.wooz.org>
	<CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>
	<CAF_E5JbNNQdN=4rPbY8e6UmBb=FVXgUs8SdAS2_Yn6ehipUqKA@mail.gmail.com>
Message-ID: <CAL_0O1_uWcB9sOGpDGnpYidgcp+GZW0Pj4n2iOuxiCz3+JUYzg@mail.gmail.com>

But how does the option get into your web UI?  If you have to put it
in there by editing
mm_config, I don't see the gain.  Remember, many archivers already
have the rather
convenient (to non-shell-on-Mailman-host list owners and even ordinary
users) UI of
simply subscribing the archiver to the list.

I would say that one way to implement this would be as a role in the
user database.
Instead of subscribing an archiver as "member", subscribe it with the
"archivist" role.
Gmane would probably be willing to do this, for example, if the
subscription method
were as simple as subscribing an ordinary member.  I suppose the same goes for
mail-archive.com.

On Fri, Mar 23, 2012 at 10:13 AM, andrea crotti
<andrea.crotti.0 at gmail.com> wrote:
> My idea as a user would be to be able to select from my
> web configuration page an option:
>
> send_public_url_in_mail_footers: [
> disabled,
> gmane_url,
> mailmanweb_url
> ]
>
> And maybe it would be cool (if possible I have no idea) to add a mail
> command that when I send
>
> subject: public $mailing_list $id
>
> I get back an email with this url. ?Because maybe from one mailing list
> I'm normally not interested in the url and I also want it in some cases.
>
> Not sure I anyone else in the world would like this feature though :D
> _______________________________________________
> 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/stephen%40xemacs.org
>
> Security Policy: http://wiki.list.org/x/QIA9

From CNulk at scu.edu  Fri Mar 23 17:51:12 2012
From: CNulk at scu.edu (C Nulk)
Date: Fri, 23 Mar 2012 09:51:12 -0700
Subject: [Mailman-Developers] bugs on launchpad
In-Reply-To: <CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>
References: <4F6380DF.4000708@gmail.com>
	<20120322200938.04921f6b@resist.wooz.org>
	<CAL_0O1-w7tDoDGoSRnB8BBi_VknTBZFE-XzknOTXOMOuBipXDw@mail.gmail.com>
Message-ID: <4F6CAA00.7060806@scu.edu>

On 3/22/2012 5:48 PM, Stephen J. Turnbull wrote:
> On Fri, Mar 23, 2012 at 1:09 AM, Barry Warsaw <barry at list.org> wrote:
>
>> If we add something like $archive_url to the decoration interpolation
>> dictionary, what happens when we have multiple archivers that support
>> permalink() enabled?  Do we chose one at random (these are unordered)?
> -1

I agree so -2.  I thinking is if you list administrator/owner has not
defined an order, make it simple and impose a known order in that case -
alphabetize/sort the order and pick the first one.

>
>> Do we add a configuration variable to select a "primary" archiver for this?
> +1

+2

 This would allow the list administrator/owner to define and pick the
primary archiver.  For any other archivers, people can go to the
Archived-At header(s).

>
> If there's *no* archiver configuration variable, we don't know where to
> point to anyway for Gmane-like archivers (yes, I know, catering to Gmane
> will give Brad hives, but some people like Gmane).  The local archive, if it
> exists, may seem TOOWTDI, but it might not be the preferred one even if
> it's the only one configured in Mailman (although that seems a lot less
> likely than the case where somebody just grandfathers an existing Gmane
> subscription as the archive URL of choice).
>
>> Do we allow something like $archive_url.prototype as an interpolation
>> variable to select e.g. the 'prototype' archiver?
> -1
>
> Too complex.  If people want alternative archives, they can go to
> the list FAQ or the Archived-At headers.  If we go this way, we'd
> better have a *really* good comment and a pre-existing entry in
> the FAQ to save Mark some time. :-)

I agree with Stephen.  Too complex and can be confusing without it being
well documented with a number of examples.



From andrea.crotti.0 at gmail.com  Fri Mar 23 21:19:53 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Fri, 23 Mar 2012 20:19:53 +0000
Subject: [Mailman-Developers] python 3
Message-ID: <4F6CDAE9.9040807@gmail.com>

Someone told me that I should poke Barry about Python3 support, so here
I am ;)

It's clearly something that can be done really soon, but I think it's
worth to start thinking about it.

In particular I noticed that lazr.config have been untouched since 2009,
which makes me think that is less likely that they will be ported to
Python 3.

Is it a valid assumption or there is a porting plan?

Are there any other blocking factors in general from libraries or other
issues??

From vikashagrawal1990 at gmail.com  Fri Mar 23 22:49:38 2012
From: vikashagrawal1990 at gmail.com (vikash agrawal)
Date: Sat, 24 Mar 2012 03:19:38 +0530
Subject: [Mailman-Developers] GSoC 2012
Message-ID: <CAKpG3NjD=N6BLMwMfbWvsdC+CARYvowaZqKfxbgnk3ft2M_b_A@mail.gmail.com>

Hi Everyone,
I am Vikash and very much interested in contributing to mailman and being a
GSoC student this year. So far, I have successfully installed mailman in my
system.
I do have skills in Python 2.7 but as I am very new to mailman thus I am
looking for something small to hack and doable in this summer.
Also, the idea page doesnot mention the skills required for the project so
its somewhat difficult for me to choose one. As a result I would like you
to guide me over the same .
I am willing to learn a lot this summer :-)
Regards
Vikash Agrawal
-- 
sent via HTC Sensation

From barry at list.org  Sat Mar 24 00:15:29 2012
From: barry at list.org (Barry Warsaw)
Date: Fri, 23 Mar 2012 19:15:29 -0400
Subject: [Mailman-Developers] python 3
In-Reply-To: <4F6CDAE9.9040807@gmail.com>
References: <4F6CDAE9.9040807@gmail.com>
Message-ID: <20120323191529.24fccb14@resist.wooz.org>

On Mar 23, 2012, at 08:19 PM, Andrea Crotti wrote:

>Someone told me that I should poke Barry about Python3 support, so here
>I am ;)
>
>It's clearly something that can be done really soon, but I think it's
>worth to start thinking about it.

Probably you meant s/can/can't/ ... but still, it may not be so dire.  It
won't happen for Mailman 3.0 but I think it should definitely be a goal for
Mailman 3.1 (which will *not* take another 4 years :).

I've tried to be very careful in writing Mailman 3 so that *its* code should
be relatively easy to port to Python 3.  No doubt there will be gotchas, but I
am definitely keeping that in mind as I go.

>In particular I noticed that lazr.config have been untouched since 2009,
>which makes me think that is less likely that they will be ported to
>Python 3.
>
>Is it a valid assumption or there is a porting plan?
>
>Are there any other blocking factors in general from libraries or other
>issues??

Really, we need to get our dependency stack ported.  I'm committed to making
Mailman 3 a Python 3 application as soon as it's possible.  Martin von Loewis
was working on porting Storm at Pycon, which obviously is a critical
component, but I don't think he quite finished.

We need restish.io ported, along with its dependency stack, as well as several
of the still-unported Zope libraries, and *their* dependency stacks.  By
looking in buildout's eggs directory, you can get a good sense of what is
currently required:

flufl.bounce-2.1-py2.7.egg/
flufl.enum-3.3.1-py2.7.egg/
flufl.i18n-1.1-py2.7.egg/
flufl.lock-2.2-py2.7.egg/
flufl.password-1.2-py2.7.egg/
httplib2-0.7.4-py2.7.egg/
lazr.config-1.1.3-py2.7.egg/
lazr.delegates-1.2.0-py2.7.egg/
lazr.smtptest-1.3-py2.7.egg/
mimeparse-0.1.3-py2.7.egg/
restish-0.12.1-py2.7.egg/
setuptools-0.6c12dev_r88846-py2.7.egg/
six-1.1.0-py2.7.egg/
storm-0.19-py2.7-linux-x86_64.egg/
WebOb-1.2b3-py2.7.egg/
z3c.recipe.scripts-1.0.1-py2.7.egg/
z3c.recipe.tag-0.4.1-py2.7.egg/
zc.buildout-1.5.2-py2.7.egg/
zc.recipe.egg-1.3.2-py2.7.egg/
zc.recipe.testrunner-1.4.0-py2.7.egg/
zope.component-3.12.0-py2.7.egg/
zope.configuration-3.8.0-py2.7.egg/
zope.event-3.5.1-py2.7.egg/
zope.exceptions-3.6.1-py2.7.egg/
zope.i18nmessageid-3.6.1-py2.7-linux-x86_64.egg/
zope.interface-3.8.0-py2.7-linux-x86_64.egg/
zope.schema-4.0.1-py2.7.egg/
zope.testing-3.10.3-py2.7.egg/
zope.testrunner-4.0.4-py2.7.egg/

The flufl packages are of course ported. :)

Not all of that will be needed.  For example, I do want to eventually get rid
of zc.buildout, zope.testing, and zope.testrunner, so some of those
dependencies will go away as a result of that.

The best way to help is to work with those upstreams to get official Python 3
support in their libraries.  If you're looking for guidance, start with storm,
WebOb, restish, lazr.*, and the unported zope.* libraries (minus .testing and
.testrunner, and possibly .i18nmessageid). 

The email6 package availability will probably help us a lot too.  Help
R. David Murray on that package, or just pay him money to finish it. :)

Cheers,
-Barry

From barry at list.org  Sat Mar 24 03:00:13 2012
From: barry at list.org (Barry Warsaw)
Date: Fri, 23 Mar 2012 22:00:13 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius
	1.0 alpha 1
Message-ID: <20120323220013.0b1c88a8@resist.wooz.org>

Hello Mailman enthusiasts!

    Use the key, unlock the door
    See what your fate might have in store...

Building on the excitement and amazing progress at our sprints at Pycon 2012,
I am very happy to announce the availability of GNU Mailman 3.0 beta 1, code
named "The Twilight Zone".

After nearly four years of design, discussion, and development, we can now see
a clear path to a final release.  I thank everyone who has helped us get here,
by participating on the mailman-developers mailing list, the bug tracker, in
private conversations, and code contributions, both to Mailman itself and all
the great projects it builds on.  Special thanks go to our recent sprinters,
Andrea Crotti, Florian Fuchs, Toshio Kuratomi, Daniel Mizyrycki, Terri Oda,
Mark Sapiro, and Stephen Turnbull.

While you do want to be careful using 3.0b1 in production, I hope that you
will get a copy of the code and run it through its paces.  Several people are
known to be running real mailing lists using the code base.  At this point,
the feature set is frozen, as is the database schema.  We'll use the schema
migration machinery to do any schema changes from here to the final release.

I'm also ecstatic to announce the first alpha release of Postorius, our new
official name for the Django-based Mailman 3 web user interface.  The name was
suggested by core developer Florian Fuchs in honor of a bass hero of both of
ours, Jaco Pastorius.  Postorius 1.0 alpha 1 is code named "Space Farm".

Postorius is in large part based on the great work of Anna Senarclens de
Grancy and Benedict Stein who worked on a new Mailman web ui during their
Google Summer of Code projects in 2010 and 2011.  This alpha version connects
to Mailman 3.0's REST API to add and edit lists and domains, as well as to
moderate messages.  It uses Django's auth app and Mozilla's BrowserID for
authentication (a list of the current features is contained in the NEWS file
of the package).  Apart from the current state there are many more ideas left
for the upcoming releases.  There is a great team working on the web ui as
well as on a new archiver, so stay tuned, and come join us!

You can download GNU Mailman 3.0b1 from Launchpad or the Python Cheeseshop:

    https://launchpad.net/mailman
    http://pypi.python.org/pypi/mailman

Postorius 1.0a1 is available from Launchpad and Cheeseshop as well:

    https://launchpad.net/postorius
    http://pypi.python.org/pypi/postorius

The GNU Mailman documentation is available online at:

    http://packages.python.org/mailman/

You can submit bug reports to GNU Mailman and Postorius at:

    https://bugs.launchpad.net/mailman
    https://bugs.launchpad.net/postorius

GNU Mailman and Postorius are released under the GNU General Public License
version 3 or later.

Enjoy!
-Barry
(On behalf of the entire GNU Mailman development team)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120323/f2d0fad4/attachment.pgp>

From hopkinsju at umsystem.edu  Sat Mar 24 03:05:12 2012
From: hopkinsju at umsystem.edu (Hopkins, Justin)
Date: Sat, 24 Mar 2012 02:05:12 +0000
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius	1.0 alpha 1
In-Reply-To: <20120323220013.0b1c88a8@resist.wooz.org>
References: <20120323220013.0b1c88a8@resist.wooz.org>
Message-ID: <3823422B-314B-4EC1-9803-F7E19A852D03@umsystem.edu>

On Mar 23, 2012, at 9:00 PM, "Barry Warsaw" <barry at list.org> wrote:

> Use the key, unlock the door
>    See what your fate might have in store...

Everybody walk the dinosaur!

Seriously though, this is amazing news! Thanks to everyone who helped work on this. I can't wait to give it a try!

Cheers,
Justin

From felipe at felipegasper.com  Sat Mar 24 05:47:23 2012
From: felipe at felipegasper.com (Felipe Gasper)
Date: Fri, 23 Mar 2012 23:47:23 -0500
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <20120323220013.0b1c88a8@resist.wooz.org>
References: <20120323220013.0b1c88a8@resist.wooz.org>
Message-ID: <4F6D51DB.4060803@felipegasper.com>

No INSTALL file in the tarball?

For folks like me who aren?t savvy with Python?s installers and were 
expecting to find configure/make, it would help a great deal.


This may be the wrong list for this, but just in case I stumbled on the 
right way to install it, I got this when doing sudo python setup.py install:

-----------
Processing dependencies for mailman==3.0.0b1
error: Installed distribution zope.interface 3.5.1 conflicts with 
requirement zope.interface>=3.8.0
-----------

-FG

On 23.3.12 9:00 PM, Barry Warsaw wrote:
> Hello Mailman enthusiasts!
>
>      Use the key, unlock the door
>      See what your fate might have in store...
>
> Building on the excitement and amazing progress at our sprints at Pycon 2012,
> I am very happy to announce the availability of GNU Mailman 3.0 beta 1, code
> named "The Twilight Zone".
>
> After nearly four years of design, discussion, and development, we can now see
> a clear path to a final release.  I thank everyone who has helped us get here,
> by participating on the mailman-developers mailing list, the bug tracker, in
> private conversations, and code contributions, both to Mailman itself and all
> the great projects it builds on.  Special thanks go to our recent sprinters,
> Andrea Crotti, Florian Fuchs, Toshio Kuratomi, Daniel Mizyrycki, Terri Oda,
> Mark Sapiro, and Stephen Turnbull.
>
> While you do want to be careful using 3.0b1 in production, I hope that you
> will get a copy of the code and run it through its paces.  Several people are
> known to be running real mailing lists using the code base.  At this point,
> the feature set is frozen, as is the database schema.  We'll use the schema
> migration machinery to do any schema changes from here to the final release.
>
> I'm also ecstatic to announce the first alpha release of Postorius, our new
> official name for the Django-based Mailman 3 web user interface.  The name was
> suggested by core developer Florian Fuchs in honor of a bass hero of both of
> ours, Jaco Pastorius.  Postorius 1.0 alpha 1 is code named "Space Farm".
>
> Postorius is in large part based on the great work of Anna Senarclens de
> Grancy and Benedict Stein who worked on a new Mailman web ui during their
> Google Summer of Code projects in 2010 and 2011.  This alpha version connects
> to Mailman 3.0's REST API to add and edit lists and domains, as well as to
> moderate messages.  It uses Django's auth app and Mozilla's BrowserID for
> authentication (a list of the current features is contained in the NEWS file
> of the package).  Apart from the current state there are many more ideas left
> for the upcoming releases.  There is a great team working on the web ui as
> well as on a new archiver, so stay tuned, and come join us!
>
> You can download GNU Mailman 3.0b1 from Launchpad or the Python Cheeseshop:
>
>      https://launchpad.net/mailman
>      http://pypi.python.org/pypi/mailman
>
> Postorius 1.0a1 is available from Launchpad and Cheeseshop as well:
>
>      https://launchpad.net/postorius
>      http://pypi.python.org/pypi/postorius
>
> The GNU Mailman documentation is available online at:
>
>      http://packages.python.org/mailman/
>
> You can submit bug reports to GNU Mailman and Postorius at:
>
>      https://bugs.launchpad.net/mailman
>      https://bugs.launchpad.net/postorius
>
> GNU Mailman and Postorius are released under the GNU General Public License
> version 3 or later.
>
> Enjoy!
> -Barry
> (On behalf of the entire GNU Mailman development team)
>
>
>
> _______________________________________________
> 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/felipe%40felipegasper.com
>
> Security Policy: http://wiki.list.org/x/QIA9


From mark at msapiro.net  Sat Mar 24 07:33:47 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 23 Mar 2012 23:33:47 -0700
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F6D51DB.4060803@felipegasper.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<4F6D51DB.4060803@felipegasper.com>
Message-ID: <4F6D6ACB.9090309@msapiro.net>

On 3/23/2012 9:47 PM, Felipe Gasper wrote:
> No INSTALL file in the tarball?
> 
> For folks like me who aren?t savvy with Python?s installers and were
> expecting to find configure/make, it would help a great deal.
> 
> 
> This may be the wrong list for this, but just in case I stumbled on the
> right way to install it, I got this when doing sudo python setup.py
> install:


The installation is

python bootstrap.py
bin/buildout

This and the following steps are described in more detail in
src/mailman/docs/START.rst

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From stephen at xemacs.org  Sat Mar 24 15:41:59 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 24 Mar 2012 15:41:59 +0100
Subject: [Mailman-Developers] python 3
In-Reply-To: <20120323191529.24fccb14@resist.wooz.org>
References: <4F6CDAE9.9040807@gmail.com>
	<20120323191529.24fccb14@resist.wooz.org>
Message-ID: <CAL_0O19twWQByzPEGY0gi-3HhMg6gC24XRJeO80NqTEjrrtcgQ@mail.gmail.com>

On Sat, Mar 24, 2012 at 12:15 AM, Barry Warsaw <barry at list.org> wrote:
> Not all of that will be needed. ?For example, I do want to eventually get rid
> of zc.buildout, zope.testing, and zope.testrunner, so some of those
> dependencies will go away as a result of that.

But presumably new dependencies will be added to support those
functions, and while Python 3 support is an important desideratum,
for replacements, I don't think that it's a good idea to let it override
quality in the implementation of dependencies.

From stephen at xemacs.org  Sat Mar 24 16:15:14 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 24 Mar 2012 16:15:14 +0100
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <20120323220013.0b1c88a8@resist.wooz.org>
References: <20120323220013.0b1c88a8@resist.wooz.org>
Message-ID: <CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>

On Sat, Mar 24, 2012 at 3:00 AM, Barry Warsaw <barry at list.org> wrote:
> Hello Mailman enthusiasts!

> I'm also ecstatic to announce the first alpha release of Postorius, our new
> official name for the Django-based Mailman 3 web user interface. ?The name was
> suggested by core developer Florian Fuchs in honor of a bass hero of both of
> ours, Jaco Pastorius. ?Postorius 1.0 alpha 1 is code named "Space Farm".

I can't wait for "Gene Simmons" and "Tal Wilkenfeld"! :-)

From barry at list.org  Sat Mar 24 17:54:23 2012
From: barry at list.org (Barry Warsaw)
Date: Sat, 24 Mar 2012 12:54:23 -0400
Subject: [Mailman-Developers] python 3
In-Reply-To: <CAL_0O19twWQByzPEGY0gi-3HhMg6gC24XRJeO80NqTEjrrtcgQ@mail.gmail.com>
References: <4F6CDAE9.9040807@gmail.com>
	<20120323191529.24fccb14@resist.wooz.org>
	<CAL_0O19twWQByzPEGY0gi-3HhMg6gC24XRJeO80NqTEjrrtcgQ@mail.gmail.com>
Message-ID: <20120324125423.75119ae1@resist.wooz.org>

On Mar 24, 2012, at 03:41 PM, Stephen J. Turnbull wrote:

>On Sat, Mar 24, 2012 at 12:15 AM, Barry Warsaw <barry at list.org> wrote:
>> Not all of that will be needed. ?For example, I do want to eventually get rid
>> of zc.buildout, zope.testing, and zope.testrunner, so some of those
>> dependencies will go away as a result of that.
>
>But presumably new dependencies will be added to support those
>functions, and while Python 3 support is an important desideratum,
>for replacements, I don't think that it's a good idea to let it override
>quality in the implementation of dependencies.

Agreed.  However, In these cases, there are already compelling technical
reasons to find replacements.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120324/f1b51037/attachment.pgp>

From jeff at jab.org  Sun Mar 25 23:34:20 2012
From: jeff at jab.org (Jeff Breidenbach)
Date: Sun, 25 Mar 2012 14:34:20 -0700
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
Message-ID: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>

Congratulations! I was able to get Postorius running by following the
five minute quick start guide. I didn't see archiving settings in the
user interface, how do I set that up?

Cheers,
Jeff

From sidharthbansal.sb at gmail.com  Sun Mar 25 23:45:53 2012
From: sidharthbansal.sb at gmail.com (Sidharth Bansal)
Date: Mon, 26 Mar 2012 03:15:53 +0530
Subject: [Mailman-Developers] Need guidance to start contributing to Mailman
Message-ID: <CAKdU976n_jDo6dzRaJdVEVOcfWd5289_v5C8UzMNDzkKKgK4Hg@mail.gmail.com>

Hello Mailman Developers,
  Sorry in advance if this is not the right place for my query.
I wanted to start contributing to Mailman-Development, and wanted a little
head start for that. I would love to get any sort of guidance in this
respect. I am a second year IT student with knowledge of c, c++, and trying
my hands on web development.
     Thanks

From mark at msapiro.net  Mon Mar 26 00:48:53 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Mar 2012 15:48:53 -0700
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
	andPostorius 1.0 alpha 1
In-Reply-To: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
Message-ID: <PC195201203251548530765aee868f2@MSAPIRO>

Jeff Breidenbach wrote:

>Congratulations! I was able to get Postorius running by following the
>five minute quick start guide. I didn't see archiving settings in the
>user interface, how do I set that up?


We've finally ditched Pipermail for archiving. Archiving in MM3 will be
"pluggable" and archiving projects are being worked on with more work
scheduled for GSoC this summer.

In the mean time, for public archives at least, you can use
mail-archive.com or some other archiving service.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Mon Mar 26 03:35:47 2012
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Mar 2012 18:35:47 -0700
Subject: [Mailman-Developers] I18n help needed for Mailman 2.1.15 release.
Message-ID: <4F6FC7F3.80502@msapiro.net>

Now that Mailman 3 is in beta, I would like to spend more time working
on it. To that end, I am planning to release Mailman 2.1.15 soon. This
release fixes quite a few bugs and adds some needed new features. See
the NEWS file at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/NEWS> for
details.

This release contains several new message strings and a template
modification, none of which have been translated. So, if you are a
language champion or just an interested user or anything between, I need
your help.

There is a new feature to request a password reminder from the private
archive login page. This necessitated an addition to
templates/<language>/private.html. I have added the new information to
all the templates, but it is in English. If you can help translate this
into your language, get the private.html template from your language
directory at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/templates/>,
and send me a translated template.

Also, all the message catalogs have been merged from the new mailman.pot
and there are fuzzy translations and untranslated strings as a result.
If you can help with fixing these, get the current
LC_MESSAGES/mailman.po file from your language directory at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/messages/>
and send me an updated version.

If you can help with this, please do it before the end of April. If you
want to help but aren't sure what to do, let me know and I'll try to
help you.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From andrea.crotti.0 at gmail.com  Mon Mar 26 17:11:47 2012
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 26 Mar 2012 16:11:47 +0100
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <20120323220013.0b1c88a8@resist.wooz.org>
References: <20120323220013.0b1c88a8@resist.wooz.org>
Message-ID: <4F708733.2040600@gmail.com>

On 03/24/2012 02:00 AM, Barry Warsaw wrote:
> Hello Mailman enthusiasts!
>
>      Use the key, unlock the door
>      See what your fate might have in store...
>
> Building on the excitement and amazing progress at our sprints at Pycon 2012,
> I am very happy to announce the availability of GNU Mailman 3.0 beta 1, code
> named "The Twilight Zone".
>
> After nearly four years of design, discussion, and development, we can now see
> a clear path to a final release.  I thank everyone who has helped us get here,
> by participating on the mailman-developers mailing list, the bug tracker, in
> private conversations, and code contributions, both to Mailman itself and all
> the great projects it builds on.  Special thanks go to our recent sprinters,
> Andrea Crotti, Florian Fuchs, Toshio Kuratomi, Daniel Mizyrycki, Terri Oda,
> Mark Sapiro, and Stephen Turnbull.
>
> While you do want to be careful using 3.0b1 in production, I hope that you
> will get a copy of the code and run it through its paces.  Several people are
> known to be running real mailing lists using the code base.  At this point,
> the feature set is frozen, as is the database schema.  We'll use the schema
> migration machinery to do any schema changes from here to the final release.
>
> I'm also ecstatic to announce the first alpha release of Postorius, our new
> official name for the Django-based Mailman 3 web user interface.  The name was
> suggested by core developer Florian Fuchs in honor of a bass hero of both of
> ours, Jaco Pastorius.  Postorius 1.0 alpha 1 is code named "Space Farm".
>
> Postorius is in large part based on the great work of Anna Senarclens de
> Grancy and Benedict Stein who worked on a new Mailman web ui during their
> Google Summer of Code projects in 2010 and 2011.  This alpha version connects
> to Mailman 3.0's REST API to add and edit lists and domains, as well as to
> moderate messages.  It uses Django's auth app and Mozilla's BrowserID for
> authentication (a list of the current features is contained in the NEWS file
> of the package).  Apart from the current state there are many more ideas left
> for the upcoming releases.  There is a great team working on the web ui as
> well as on a new archiver, so stay tuned, and come join us!
>
> You can download GNU Mailman 3.0b1 from Launchpad or the Python Cheeseshop:
>
>      https://launchpad.net/mailman
>      http://pypi.python.org/pypi/mailman
>
> Postorius 1.0a1 is available from Launchpad and Cheeseshop as well:
>
>      https://launchpad.net/postorius
>      http://pypi.python.org/pypi/postorius
>
> The GNU Mailman documentation is available online at:
>
>      http://packages.python.org/mailman/
>
> You can submit bug reports to GNU Mailman and Postorius at:
>
>      https://bugs.launchpad.net/mailman
>      https://bugs.launchpad.net/postorius
>
> GNU Mailman and Postorius are released under the GNU General Public License
> version 3 or later.
>
> Enjoy!
> -Barry
> (On behalf of the entire GNU Mailman development team)
>

Great news Barry, but just one thing, I checked now on list.org and the 
GNU Mailman
website and there is no mention of this release.. is that on purpose?

From mdoshayan at gmail.com  Mon Mar 26 13:27:44 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Mon, 26 Mar 2012 16:57:44 +0530
Subject: [Mailman-Developers] Google Summer of Code: Integration of Search
	Code
Message-ID: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>

Hi,

I am Shayan, I am doing my masters from IISc Bangalore. I want to take part
in GSoC from mailman organization. I have fairly good experience in python.
I worked on whoosh library for my own project. I have experience with
django also.

I am planning to work on integrating systers search code into mailman. I
believe for whole summer this task alone is very small. I'll include couple
of more tasks in the proposal.

I went through search code. Code looks pretty standard. As far I understood

mailman.Searcher.IndexSchema has whoosh schema
mailman.Seracher.Indexer contains indexing functions which are later used
in genindex.py
mailman.Seracher.Mailocate has search function for indexed content
generated by genindex.py

mailman.bin.genindex.main() is the main function which indexes the archives

I am still trying to figure out how mailman client library interacts with
mailman server. I know how to use client library but I couldn't understand
internal working of mailman server. I have been reading the code but I
wasn't able understand much. It would be awesome if you can point me to any
documentation to understand this. Some api documentation or anything to
understand code.

Thanks

Shayan.

From barry at list.org  Mon Mar 26 19:38:24 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 26 Mar 2012 13:38:24 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F6D51DB.4060803@felipegasper.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<4F6D51DB.4060803@felipegasper.com>
Message-ID: <20120326133824.79258e93@rivendell>

On Mar 23, 2012, at 11:47 PM, Felipe Gasper wrote:

>No INSTALL file in the tarball?
>
>For folks like me who aren?t savvy with Python?s installers and were
>expecting to find configure/make, it would help a great deal.
>
>This may be the wrong list for this, but just in case I stumbled on the right
>way to install it, I got this when doing sudo python setup.py install:
>
>-----------
>Processing dependencies for mailman==3.0.0b1
>error: Installed distribution zope.interface 3.5.1 conflicts with requirement zope.interface>=3.8.0
>-----------

The online documentation is here:

http://packages.python.org/mailman/README.html

but I admit that the "Getting Started" page is a little bit out of date.  It's
mostly right though.  You can also build mm3 in a virtualenv, which is how I
actually run it in my test-production servers.

This would make a nice easy bug for someone to work on.  I've added two
official bug tags to the tracker: 'documentation' and 'easy'.  Just go to
http://bugs.launchpad.net/mailman and use the advanced search to find bugs
with either of these tags.  If it also has a 'mailman3' official bug tag, then
you'll know it's targeted for Mailman 3.

Cheers,
-Barry

From barry at python.org  Mon Mar 26 19:39:51 2012
From: barry at python.org (Barry Warsaw)
Date: Mon, 26 Mar 2012 13:39:51 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F708733.2040600@gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<4F708733.2040600@gmail.com>
Message-ID: <20120326133951.34c0dc9d@rivendell>

On Mar 26, 2012, at 04:11 PM, Andrea Crotti wrote:

>Great news Barry, but just one thing, I checked now on list.org and the GNU
>Mailman website and there is no mention of this release.. is that on purpose?

Not really.  The server moved recently and my keys hadn't been installed.
Looks like they still aren't, so let me ping the admins.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120326/1b988964/attachment.pgp>

From barry at list.org  Mon Mar 26 19:54:03 2012
From: barry at list.org (Barry Warsaw)
Date: Mon, 26 Mar 2012 13:54:03 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
Message-ID: <20120326135403.2da7e732@rivendell>

On Mar 25, 2012, at 02:34 PM, Jeff Breidenbach wrote:

>Congratulations! I was able to get Postorius running by following the
>five minute quick start guide. I didn't see archiving settings in the
>user interface, how do I set that up?

As Mark described, mm3 actually has a nicer architecture for archive
integration.  You can define multiple archivers system-wide, and there is an
interface you can implement if you want to add a new one.

Archivers are configured in the mailman.cfg file; i.e. they are system-wide.
They cannot currently be configured per-list, although it might be interesting
to someday support enabling or disabling them on a per-list basis.  Maybe. ;)

Note that beta2 will have a somewhat improved implementation here.  Each
archiver can have a "clobber policy" and "skew interval" which generalizes the
old Pipermail Date: header clobbering rules, so that it can apply to any
archiver.

The Mail Archive is already supported in mm3, using the RFC 5064 standard and
the X-Message-ID-Hash we discussed a while back. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120326/444fec9f/attachment.pgp>

From a.badger at gmail.com  Mon Mar 26 21:41:07 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 26 Mar 2012 12:41:07 -0700
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
Message-ID: <20120326194107.GX11151@unaka.lan>

On Mon, Mar 26, 2012 at 04:57:44PM +0530, Shayan Md wrote:
> Hi,
> 
> I am Shayan, I am doing my masters from IISc Bangalore. I want to take part
> in GSoC from mailman organization. I have fairly good experience in python.
> I worked on whoosh library for my own project. I have experience with
> django also.
> 
> I am planning to work on integrating systers search code into mailman. I
> believe for whole summer this task alone is very small. I'll include couple
> of more tasks in the proposal.
> 
> I went through search code. Code looks pretty standard. As far I understood
> 
> mailman.Searcher.IndexSchema has whoosh schema
> mailman.Seracher.Indexer contains indexing functions which are later used
> in genindex.py
> mailman.Seracher.Mailocate has search function for indexed content
> generated by genindex.py
> 
> mailman.bin.genindex.main() is the main function which indexes the archives
> 
> I am still trying to figure out how mailman client library interacts with
> mailman server. I know how to use client library but I couldn't understand
> internal working of mailman server. I have been reading the code but I
> wasn't able understand much. It would be awesome if you can point me to any
> documentation to understand this. Some api documentation or anything to
> understand code.
> 
Is this integration to be done with mailman2 or mailman3?

In mailman3, the archivers are separated from the mailman core.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120326/01a5edd2/attachment-0001.pgp>

From sophron at latthi.com  Mon Mar 26 23:38:38 2012
From: sophron at latthi.com (George Chatzisofroniou)
Date: Tue, 27 Mar 2012 00:38:38 +0300
Subject: [Mailman-Developers] [GSoC 2012] Candidate on 'Integration of
 (existing) search code into Mailman archives'
Message-ID: <CACeRBzkPqWpDfSt4KqtACYSTaOdSxBuTaoMixJ=Tbq_dOHGBAQ@mail.gmail.com>

Hello Mailman Developers,

My name is George Chatzisofroniou, i'm 20 years old and i'm an
undergraduate student in the Department of Informatics at the
University of Piraeus (Greece).

? have really good previous experience with Mailman. This is because i
use it for managing mailing lists for almost three years.

I have also developed, with a friend of mine, MailmanStats [1], a
Python software that outputs statistics for a mailing list based on
Mailman. I think this implements the 'metric' idea in some way. I
would like to know your opinion about MailmanStats.

I'm sending this mail to inform you about my will to be part of
Mailman Development team starting by Google Summer of Code 2012. The
idea that excites me more is the 'Integration of (existing) search
code into Mailman archives'. I think it is better to be developed on
Mailman v3 rather than v2. I realize the significance of a feature
like this. Many times before, i've got through the archives to search
for a specific thread, so an addition like this would be great!

As another student mentioned this idea is kinda small for the whole
summer, so if there is time left i could integrate my MailmanStats [1]
software into Mailman and/or build CSS styles for the web UI.

Please tell me what you think. I'm also on IRC by the name sophron.

Thanks,

[1]: http://mailmanstats.latthi.com/



-- 
George Chatzisofroniou
sophron.latthi.com

From anitacorr at gmail.com  Mon Mar 26 19:03:08 2012
From: anitacorr at gmail.com (Ana Cutillas)
Date: Mon, 26 Mar 2012 19:03:08 +0200
Subject: [Mailman-Developers] GSoC
Message-ID: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>

Hi,

my name is Ana Cutillas and I am a senior Computer Science student from
Spain. I am really interested in working on the Mailman project either with
you directly or with Systers.

I have been reading the list of ideas to implement and I am very interested
in the #6 Creating user profiles (
http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/). I have been
wanting to work on a project that involved data mining for a while now and
I think this could be a good opportunity.

In general, I think profiles should have the really straightforward
information: last time they started a conversation, last time they sent an
email to the list, when did they sign up, what time of the day are they
more active, etc. But it should be fairly easy to add cool stuff like, in
case a list allows the use of more than one language, the language the user
uses the most and maybe even percentages of usage, and with some
information retrieval we could get keywords to know what they like to talk
about the most.

I like some of the other ideas too, so I can talk to you about them if you
want to.

Hoping to hear from you soon!

- Ana

From davidj at gmail.com  Tue Mar 27 00:20:05 2012
From: davidj at gmail.com (David Jeske)
Date: Mon, 26 Mar 2012 15:20:05 -0700
Subject: [Mailman-Developers] any interest in a new built-in web-archive?
	(i.e. pipermail replacement)
Message-ID: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>

I'm writing to find out the state of and philosophy surrounding pipermail
in mailman, to see if there is a productive way to provide some
code/development-time to that part of mailman.

I know there are several decent third-party archivers out there, but many
of the mailing list archives I browse regularly are using pipermail because
it's the mailman default.... one less thing to install, administer, and
upgrade.  Unfortunately, pipermail doesn't do a good job formatting
messages for html.. (messages with no line-breaks are the most annoying
problem I regularly run into)

I've written code for this a number of times (eGroups, Yahoo Groups, Google
Groups). I also released an open-source python/clearsilver/sqlite based
archiver with redundant text-eliding, a few different thread views, and
search...  ( http://www.clearsilver.net/archive/ ) which is hardly used
both because I don't try to popularize it, and because many sites just
leave the default (pipermail).

If there is some code (and time) I can contribute to mailman/pipermail, I'd
like to do so. I'm writing this message to "take a temperature" and find
out what, if any, contributions would be appreciated the mailman
development team. I could imagine answers like:

a) pipermail is fine... if you want to fix a bug or two submit a patch, but
we don't want to improve it
b) we're ditching pipermail entirely... in the future sites will have to
choose an install an external archiver
c) we'd love pipermail to be improved... but we still want it to be simple,
static-html, and dependency free
d) we'd love a dynamic-ui replacement for pipermail... as long as it uses
the same cgi/templating model as mailman ui

Thoughts? Is there any help I can offer up here?

From a.badger at gmail.com  Tue Mar 27 02:11:52 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 26 Mar 2012 17:11:52 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
Message-ID: <20120327001152.GY11151@unaka.lan>

On Mon, Mar 26, 2012 at 03:20:05PM -0700, David Jeske wrote:
> I'm writing to find out the state of and philosophy surrounding pipermail
> in mailman, to see if there is a productive way to provide some
> code/development-time to that part of mailman.
> 
> I know there are several decent third-party archivers out there, but many
> of the mailing list archives I browse regularly are using pipermail because
> it's the mailman default.... one less thing to install, administer, and
> upgrade.  Unfortunately, pipermail doesn't do a good job formatting
> messages for html.. (messages with no line-breaks are the most annoying
> problem I regularly run into)
> 
> I've written code for this a number of times (eGroups, Yahoo Groups, Google
> Groups). I also released an open-source python/clearsilver/sqlite based
> archiver with redundant text-eliding, a few different thread views, and
> search...  ( http://www.clearsilver.net/archive/ ) which is hardly used
> both because I don't try to popularize it, and because many sites just
> leave the default (pipermail).
> 
> If there is some code (and time) I can contribute to mailman/pipermail, I'd
> like to do so. I'm writing this message to "take a temperature" and find
> out what, if any, contributions would be appreciated the mailman
> development team. I could imagine answers like:
> 
> a) pipermail is fine... if you want to fix a bug or two submit a patch, but
> we don't want to improve it
> b) we're ditching pipermail entirely... in the future sites will have to
> choose an install an external archiver
> c) we'd love pipermail to be improved... but we still want it to be simple,
> static-html, and dependency free
> d) we'd love a dynamic-ui replacement for pipermail... as long as it uses
> the same cgi/templating model as mailman ui
> 
> Thoughts? Is there any help I can offer up here?
>
We'd love to have work done on the archier!  I know that we're ditching
pipermail entirely and that archivers are becoming separate from the core
mailman.  What I don't know is whether mailman3 will eventually have
a standard archiver which lives outside of the core mailman but is
recommended for installation along with it.

At PyCon a few weeks ago, I demoed hyperkitty which showed some of the
things that a next generation archiver could do.  hyperkitty is continuing
to be developed.  As I was talking about hyperkitty we touched briefly on
what I think is one of the central conundrums about having only unofficial
third party archivers:  how to have a consistent programatic interface
available over http.  Grackle is another archiver for mailman that doesn't
have the UI bells and whistles of hyperkitty but it does make an effort to
expose a REST UI to the world.  I think that's a beautiful thing.  But
I don't like that a site that wanted both would need to run two archivers
that were saving mail into two sets of storage.

I think there's several ways we could go about this.

* We could create a standard REST API that archivers were free but
  encouraged  to implement.
* We could expand the python API that archivers needed to expose and then
  implement the REST API inside of mailman Core (or a re-envisioned,
  lightweight Grackle).
* We could promote a standard archiver much as we're going to promote
  posterius as the standard admin front-end and that archiver would provide
  a standard REST API that others could then emulate.


hyperkitty:
Project page: https://fedorahosted.org/hyperkitty/
Code: http://bzr.fedorahosted.org/bzr/hyperkitty/
Demo: http://mm3test.fedoraproject.org/2

grackle: https://launchpad.net/grackle

(One thing I notice about grackle now is that it's AGPL... that's going to
be unpleasant for some sites to run.  Perhaps we can change that or get some
changes added to the AGPL.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120326/cb9bcd6e/attachment.pgp>

From davidj at gmail.com  Tue Mar 27 03:07:14 2012
From: davidj at gmail.com (David Jeske)
Date: Mon, 26 Mar 2012 18:07:14 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327001152.GY11151@unaka.lan>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
Message-ID: <CA+CP9O7Jvg-1EvGUuQ5jJHXWD+AcuEM0rrGxVDu7XCZrJpnNLA@mail.gmail.com>

On Mon, Mar 26, 2012 at 5:11 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:

> We'd love to have work done on the archier!  I know that we're ditching
> pipermail entirely and that archivers are becoming separate from the core
> mailman.  What I don't know is whether mailman3 will eventually have
> a standard archiver which lives outside of the core mailman but is
> recommended for installation along with it.
>

I see.. that sounds like option-b.

I highly recommend reconsidering this and including a standard archiver
with mailman. If the number of sites that use pipermail is any indication,
I think failing to include something will basically mean lots of lists
without any archives.


> At PyCon a few weeks ago, I demoed hyperkitty which showed some of the
> things that a next generation archiver could do.


I recommend you take a closer look at
ClearsilverListArchive<http://www.clearsilver.net/archive/>,
it's written in Python, Clearsilver, SQLite.. is "real open-source" (BSD
License), and hits most of the features on your  ModernArchiving wishlist
plus a bunch you didn't (author pages, redundant text elimination, cookie
preferences.

As for the features it doesn't have from your list: Editing would be easy
to add because it's sqlite (deciding on the auth system is probably more of
an issue than the editing). Anti-Crawl code is really an issue of
configuration for cheap in-memory state-management. NNTP is well. that
would be a big job that I doubt will be bitten off by something as "small"
as a list archiver.

Sadly I can't point to any lists using it at the moment, because, well,
it's hidden under a rock. I'll injest an archive of the mailman list so you
can take it for a spin.


> As I was talking about hyperkitty we touched briefly on what I think is
> one of the central conundrums about having only unofficial third party
> archivers:  how to have a consistent programatic interface available over
> http.


What is the REST UI used by? CSLA supports RSS. When it comes to a more
involved REST UI, what software would be hitting it? I don't think I'll
understand your other API/REST points until I see an answer to this.


> Grackle is another archiver for mailman that doesn't have the UI bells and
> whistles of hyperkitty but it does make an effort to expose a REST UI to
> the world.  I think that's a beautiful thing.  But I don't like that a site
> that wanted both would need to run two archivers
> that were saving mail into two sets of storage.
>

I think here you are entering into a catch-22. If you have a single storage
system, then you have a single storage schema, which means you have a
single set of things you can do fast and most other things become
impractical (because they would require synchronizing state).

I'm quite sure, for example, that the Grackle schema is not the same as the
CSLA schema, and that many CSLA features would be impossible with the
Grackle REST API. (short of just using it to suck everything down, but then
you're just duplicating).

Why is message duplication an issue?

From stephen at xemacs.org  Tue Mar 27 03:34:50 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 27 Mar 2012 10:34:50 +0900
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
Message-ID: <CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>

On Tue, Mar 27, 2012 at 7:20 AM, David Jeske <davidj at gmail.com> wrote:
> I'm writing to find out the state of and philosophy surrounding pipermail
> in mailman,

There's been a lot of discussion of this over the years; you should spend
some time in the mailman-developers and mailman-users archives
looking for it, because neither the needs nor Barry's philosophy have
changed much over that time period.  It would be really nice if somebody
would summarize it in Python-PEP fashion, but that's above and beyond
the call of duty from your point of view.  (Ie, it would be useful, but you
may prefer coding etc, and that's fine too I believe, though I don't speak
for Barry, although I occasionally get lucky channeling him ;-).

>?Unfortunately, pipermail doesn't do a good job formatting
> messages for html.. (messages with no line-breaks are the most
> annoying problem I regularly run into)

Doing a *better* job of formatting HTML (than pipermail) is easy.
Doing a  *good* job is going to be relatively hard, though.

> If there is some code (and time) I can contribute to mailman/pipermail, I'd
> like to do so.

A better pipermail probably would be a good thing, as transition to
Mailman 3 is likely to take several years, and Mailman 2 is likely to
continue to be used for several years.  However, IMO you should
focus on low-hanging fruit, as there are now much better alternatives
to the technology used in pipermail, to the point where rewriting from
scratch (or adapting a 3rd-party product) for Mailman 3 makes sense.

> a) pipermail is fine... if you want to fix a bug or two submit a patch, but
> we don't want to improve it

Pipermail is fine for EOLing Mailman 2.  Improving it would be good, but
only if archive formats don't need upgrading and at minimum expense
of effort, IMO.

> b) we're ditching pipermail entirely... in the future sites will have to
> choose an install an external archiver

Pipermail is going the way of the dodo, yes, but there will be something
bundled with Mailman, I'm pretty sure.

> d) we'd love a dynamic-ui replacement for pipermail... as long as it uses
> the same cgi/templating model as mailman ui

A dynamic UI replacement seems to be a very good idea to me.
Sites running mailman at all will be running a dynamic UI for the
admin, so I see no good reason to stick to static for the archives.

AIUI, the current philosophy is that

(1) the communication from Mailman to the archivers will be via
LMTP/SMTP, including a Mailman-specific header to identify the
message's permalink (currently the SHA1 hash of the message ID
in BASE32 format, IIRC); and

(2) the summary, search, and retrieval UI will be a separate
application from Mailman per se, which will communicate
with Mailman via the REST API for authentication and user
configuration purposes.

Some ideas that have *not* been elaborated as "philosophy", but
which I think are consistent with various desiderata and Barry's
general approach and specific statements are

(3) an archiver Handler for the pipeline will be provided, which
will store posts in maildir format and do nothing else; and

(4) a simple default summary/search/retrieval application will
be bundled with (but have a separate development cycle from)
Mailman.

Even if that's not the current philosophy <wink/> that's the
direction I would propose.

So if you have already developed some stuff, I certainly would
love to see you put it on the table as a candidate for the
Mailman 3 default archive web UI.

From stephen at xemacs.org  Tue Mar 27 04:08:03 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 27 Mar 2012 11:08:03 +0900
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327001152.GY11151@unaka.lan>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
Message-ID: <CAL_0O1-Ots4pxsWXx614yRpgTw7O_MxgXGZ_qGEKJXo6Dn8trA@mail.gmail.com>

On Tue, Mar 27, 2012 at 9:11 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Mon, Mar 26, 2012 at 03:20:05PM -0700, David Jeske wrote:

>?As I was talking about hyperkitty we touched briefly on
> what I think is one of the central conundrums about having only unofficial
> third party archivers: ?how to have a consistent programatic interface
> available over http.

I don't understand why this is an issue.  Third party archives
(no "r"!) are going to want to have their own copies of the
posts, and will be heavily duplicated in any case (if only because
they store stuff on RAID and backup regularly :-).  Communicating
with them via SMTP will be fine, and LMTP provides a reasonable
way to handle local archives efficiently -- you can even just use
a virtual user and a standard MDA for the purpose.

If a third party wants to provide archiving service, but allow the
list to supply authentication and user configuration information,
that's another kettle of fish, but that's not a question of the
archiver itself, that's going to be part of the Mailman 3 REST
API per se.

> I don't like that a site that wanted both would need to run two archivers
> that were saving mail into two sets of storage.

Agreed, but the storage issue is easy to solve for the
Mailman site itself.  Just provide a simple Handler to stuff
posts into a maildir format mail folder (as noted above, this
can communicate with a standard MDA via LMTP, and
"require" that all third party archive UI software support that
format.  Maybe if space is that big an issue, provide a
maildir-in-zipfile backend.  If they want to do something
else (eg, access an IMAP store or stuff it into a PostgreSQL
database) they can provide their own handler for that ...
surely this is trivial?

> (One thing I notice about grackle now is that it's AGPL... that's going to
> be unpleasant for some sites to run. ?Perhaps we can change that or get some
> changes added to the AGPL.)

Yes, let's stay away from copyleft, period, to get a standard
archiver that commercial sites and developers will be
comfortable with extending.  I know people are disgusted with
Plesk and especially cPanel, but (a) GPL hasn't stopped those
folks keeping their sources away from general public, and even
with AGPL, *we* would have to keep track of *their* releases
to get our hands on their changes in any timely fashion -- which
half the time we don't want anyway! -- and (b) what we're doing
is all about UI in some sense.  Even the pipeline architecture of
core Mailman is about allowing users (the script-able but not
always program-able list and site admins) to easily make
changes to their lists' configurations.  UI design is necessarily
visible, and it's unlikely to be that much of a challenge to
reproduce their changes.  The hard part will be getting the
internal design past Barry, anyway (which is one reason why
some of the more frequently-requested features provided by
cPanel Mailman, like duplicate list names across virtual servers,
haven't been added in the past).

From stephen at xemacs.org  Tue Mar 27 04:30:18 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 27 Mar 2012 11:30:18 +0900
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <20120326133824.79258e93@rivendell>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<4F6D51DB.4060803@felipegasper.com>
	<20120326133824.79258e93@rivendell>
Message-ID: <CAL_0O18ETKeFBjFXfYiiZd0fxTT-BtA08enuffU-ZJ5_EYGSzg@mail.gmail.com>

On Tue, Mar 27, 2012 at 2:38 AM, Barry Warsaw <barry at list.org> wrote:
> On Mar 23, 2012, at 11:47 PM, Felipe Gasper wrote:
>
>>No INSTALL file in the tarball?

> The online documentation is here:
>
> http://packages.python.org/mailman/README.html
>
> but I admit that the "Getting Started" page is a little bit out of date. ?It's
> mostly right though. ?You can also build mm3 in a virtualenv, which is how I
> actually run it in my test-production servers.

I spent a fair amount of time on airplanes recently, which
I used somewhat productively to do some updating of the
docs for the beta.  I haven't merged with the release code
yet, so maybe there will be conflicts, but the work is at

lp:~stephen-xemacs/mailman/beta1-docs

Highlights:
- s/alpha/beta/ as appropriate
  A few of the instructions have changed slightly, eg, docs
  are now built with "setup.py build_sphinx", not "bin/docs".
- Add some discussion of Mailman 3 philosophy (very light)
- integrate Florian's "Setup the Admin UI in 5 Minutes" guide
  cf. src/mailman/docs/WebUIin5.rst
- add a slightly edited version of Toshio's Hyperkitty README
  cf. src/mailman/docs/ArchiveUIin5.rst

This branch is branched from my sprint-2012-overview branch
(recently merged, I see, thanks, Barry!)

I will be doing an experimental merge in the next day or so,
so I'll report on conflicts then.

(Aside to Barry: my assignment agreement will go out in the
afternoon mail ... uh, maybe not until tomorrow am at this
rate, but RSN, anyway.)

I'll add the branch URL to the bug, but I can't promise my
branch really addresses any of the issues so that's all I'll
do with it for now.

Cheers,
Steve

From stephen at xemacs.org  Tue Mar 27 04:59:19 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 27 Mar 2012 11:59:19 +0900
Subject: [Mailman-Developers] Need guidance to start contributing to
	Mailman
In-Reply-To: <CAKdU976n_jDo6dzRaJdVEVOcfWd5289_v5C8UzMNDzkKKgK4Hg@mail.gmail.com>
References: <CAKdU976n_jDo6dzRaJdVEVOcfWd5289_v5C8UzMNDzkKKgK4Hg@mail.gmail.com>
Message-ID: <CAL_0O1-kctie_DNFBb=d+EaR7VPpmv-Dg2NzvOXHYksLAMonQw@mail.gmail.com>

On Mon, Mar 26, 2012 at 6:45 AM, Sidharth Bansal
<sidharthbansal.sb at gmail.com> wrote:
> Hello Mailman Developers,
> ?Sorry in advance if this is not the right place for my query.
> I wanted to start contributing to Mailman-Development, and wanted a little
> head start for that. I would love to get any sort of guidance in this
> respect. I am a second year IT student with knowledge of c, c++, and trying
> my hands on web development.

Welcome!  This is the right place to ask.

You probably will not find C and C++ very helpful in learning web
development ... especially not Python.  You should start with the
Python tutorial (my own preference for my students is the Python 3
tutorial at

http://docs.python.org/py3k/tutorial/index.html

but you might want to start with Python 2 at

http://docs.python.org/tutorial/index.html

for web development, since many libraries are only partly ported to
Python 3 at this point).

Then you should install the Bazaar VCS for your platform

http://bazaar.canonical.com/

do "bzr help launchpad" to learn how to set up your ids for Launchpad,
where Mailman's code repository is hosted, and get the most recent
code for Mailman 3 from

lp:mailman

Then come back here, browse the mailman-developers archives, and ask questions!

Steve

From davidj at gmail.com  Tue Mar 27 07:37:48 2012
From: davidj at gmail.com (David Jeske)
Date: Mon, 26 Mar 2012 22:37:48 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
Message-ID: <CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>

> So if you have already developed some stuff, I
> certainly would love to see you put it on the table
> as a candidate for the Mailman 3 default
> archive web UI.

Yes. My CSLA code is on the table for MM2 or 3. It's python, and it's BSD.
More than that, if you folks want it, I'm happy to retool/rewrite it as
needed to make it suitable. (it has lots of great features, but i havn't
touched it in a long time and it could be better) I'll put up a demo of the
mailman list in CSLA tomorrow so folks can check it out.

I also have "some experience" with this space, and by that I mean
mountainous-experience. I coded/managed/architected several versions of
eGroups/Yahoo Groups and Google Groups, including the listprocessor, schema
design, and a few different python mail-to-html formatters. I also wrote my
own personal gmail-like web-mailer in python, which someday I'll get around
to open-sourcing.

Can you share something about dependency philosophy (besides licensing) in
Mailman?

Currently CSLA uses Clearsilver templating (BSD c-module) and sqlite
(public domain) storage.. both of which can be included directly as source
to make installation easy, but they are both c-modules.

I'm quite fond of the Clearsilver orm-to-templates toolchain, which is in
use for lots of big sites. However, I also recognize it's not that popular
in the python commmunity, mostly because we don't promote it, but also
because the template processor c-module (for performance) instead of pure
python.

If it's necessary I could convert CSLA to use django templates, though they
have a nasty design/performance problem with the orm that I think would
prevent me from using it (unless I fixed it).

I'm not a fan of javascript client-side rendering because of the generally
poor performance, poor mobile compatibility, and lack of benefit for this
kind of application.

> Doing a *better* job of formatting HTML (than pipermail) is easy.
> Doing a  *good* job is going to be relatively hard, though.

Isn't that the truth.

Back at Egroups there was a time where it seems like we used to tweak the
formatter almost daily. Deciding when preformatting is necessary vs harmful
is a real pain.

My CSLA python code has a fairly stable msg-to-html formatter that I've
been happy with for a long time. It does very aggressive automatic
repetitive text eliding for thread-display, so you can read many messages
in a thread in a single page without massive quote pileup. View-source is
provided for the unfortunate case where it does something bad.

> AIUI, the current philosophy is that
>
> (1) the communication from Mailman to the archivers
> will be via LMTP/SMTP, including a Mailman-specific
> header to identify the message's permalink (currently
> the SHA1 hash of the message ID in BASE32
> format, IIRC); and

Using SMTP for an included archiver would require it be a long running
server instead of merely a handler.

Are we talking about third-party-site archivers here?

> (2) the summary, search, and retrieval UI will be a
> separate application from Mailman per se, which will
> communicate with Mailman via the REST API for
> authentication and user configuration purposes.

That makes sense...

CSLA doesn't currently have any concept server-auth. The only stateful
features it has are view-preferences and read-state, neither of which are
important enough to require a password. It uses a password-less system
which uses cookies for prefs and a 'read state userid' which a user can
manually set if they want. I like it, because it doesn't require login to
get some basic browsing prefs and features.

Hooking up an auth system would be necessary for some of the editing ideas
in the document I read, or to allow online posting.

From mdoshayan at gmail.com  Tue Mar 27 11:31:41 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Tue, 27 Mar 2012 15:01:41 +0530
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <20120326194107.GX11151@unaka.lan>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
Message-ID: <CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>

On Tue, Mar 27, 2012 at 1:11 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:

> On Mon, Mar 26, 2012 at 04:57:44PM +0530, Shayan Md wrote:
> > Hi,
> >
> > I am Shayan, I am doing my masters from IISc Bangalore. I want to take
> part
> > in GSoC from mailman organization. I have fairly good experience in
> python.
> > I worked on whoosh library for my own project. I have experience with
> > django also.
> >
> > I am planning to work on integrating systers search code into mailman. I
> > believe for whole summer this task alone is very small. I'll include
> couple
> > of more tasks in the proposal.
> >
> > I went through search code. Code looks pretty standard. As far I
> understood
> >
> > mailman.Searcher.IndexSchema has whoosh schema
> > mailman.Seracher.Indexer contains indexing functions which are later used
> > in genindex.py
> > mailman.Seracher.Mailocate has search function for indexed content
> > generated by genindex.py
> >
> > mailman.bin.genindex.main() is the main function which indexes the
> archives
> >
> > I am still trying to figure out how mailman client library interacts with
> > mailman server. I know how to use client library but I couldn't
> understand
> > internal working of mailman server. I have been reading the code but I
> > wasn't able understand much. It would be awesome if you can point me to
> any
> > documentation to understand this. Some api documentation or anything to
> > understand code.
> >
> Is this integration to be done with mailman2 or mailman3?
>
> In mailman3, the archivers are separated from the mailman core.
>
I was working on mm3. But systers' indexer/searcher was implemented for
mailman2. So it must be easy for to integrate it with mm2.

Looks like archiver for mm3 is still in development stage. As far as I
understand searcher depends on the srchiver, right? Not completely but it
somewhat depends on archiver. I am not sure if searcher can be implemented
without archiver. If possible I can implement for mm3 also.

>
> -Toshio
>

From davidj at gmail.com  Tue Mar 27 12:38:01 2012
From: davidj at gmail.com (David Jeske)
Date: Tue, 27 Mar 2012 03:38:01 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
Message-ID: <CA+CP9O7a0mk+WvsrcUYykq=gyFY5gBpb6KOZh4ygYL+JA-ntVQ@mail.gmail.com>

I brought up a quick CSLA injest of some mailman-dev posts to show off some
basic features. I'm having a little trouble with the swish-e code, so the
features that depend on text-indexing arn't working at the moment (search,
author search).  The current UI uses user-cookies to choose between a
2-pane frames mode and a noframes mode. I set the frames-mode as the
default, which is inspired by the old google-groups usenet multi-message
tree. Use "prefs" to check out the noframes mode, which is more like
pipermail.

Take a peek more for general capabilities than UI details (unless you see
something you really like). I'm planning to change the UI to be more like
the gmail-esq conversation style UIs I've been using since then... (where
most/all of a thread's messages are rendered into a single page) I like the
outgoing google-groups UI pretty well  (not the new AJAXy one).

1) basic "home" for a list with bymonth and top-author metrics, RSS.
Extended top-author page.

http://dj1.willowmail.com/csla/Mailman-Developers
http://dj1.willowmail.com/csla/Mailman-Developers/top_authors?date=2012-03

2) Prefs, including timezone, read-status key, browse-style.. (not sure if
the read state is working on my install)

http://dj1.willowmail.com/csla/Mailman-Developers/prefs

3) threadlist for the month (frames or noframes in prefs)

http://dj1.willowmail.com/csla/Mailman-Developers/browse/month/2012-03/107

4) single-thread-list display (frames or noframes in prefs)

http://dj1.willowmail.com/csla/Mailman-Developers/threads?start=1

5) here is a good example of a thread with redundant text eliding

http://dj1.willowmail.com/csla/Mailman-Developers/browse_frm/thread/4/221

From stephen at xemacs.org  Tue Mar 27 14:32:00 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 27 Mar 2012 21:32:00 +0900
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
Message-ID: <CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>

On Tue, Mar 27, 2012 at 2:37 PM, David Jeske <davidj at gmail.com> wrote:

> Can you share something about dependency philosophy (besides licensing) in
> Mailman?

Well, for the official poop you'll have to wait for Barry, but AFAICS archivers
aren't restricted to Storm + RESTish (which is what Mailman itself uses)
because they're separate applications.  If the archiver/web UI is going to be
distributed *with* Mailman, Barry would probably prefer Storm + Django
because that's what Mailman/Protorius (core and admin web UI, resp.) are
using.  But I imagine that's negotiable as long as everything is free software.

I don't think the database backend much matters, but Mailman and Django
are both happy to use sqlite, I believe.

> I'm not a fan of javascript client-side rendering because of the generally
> poor performance, poor mobile compatibility, and lack of benefit for this
> kind of application.

Not my pidgin, you'll need to talk to Toshio/Barry about that.
>> AIUI, the current philosophy is that
>>
>> (1) the communication from Mailman to the archivers
>> will be via LMTP/SMTP, including a Mailman-specific
>> header to identify the message's permalink (currently
>> the SHA1 hash of the message ID in BASE32
>> format, IIRC); and
>
> Using SMTP for an included archiver would require it be a long running
> server instead of merely a handler.

Sure, but you're already running a sufficient server, namely
your MTA.  Of course that may not be efficient.  If an mbox or
maildir storage is sufficient, any decent MTA/MDA can do that
for you.  If not, I don't think that writing a separate handler is
a big deal; I'm just saying that AIUI the configurable Handler
provided with Mailman will certainly know how to do LMTP/
SMTP.

> Are we talking about third-party-site archivers here?

That is the motivation for choosing ?MTP as the default
transport to archivers, yes.

Steve

From barry at python.org  Tue Mar 27 15:50:44 2012
From: barry at python.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 09:50:44 -0400
Subject: [Mailman-Developers] [Bug 937154] Re: bin/disabled.py is
	nonfunctional
In-Reply-To: <20120326200337.31721.44139.malone@gac.canonical.com>
References: <20120220184758.18960.44280.malonedeb@soybean.canonical.com>
	<20120326200337.31721.44139.malone@gac.canonical.com>
Message-ID: <20120327095044.52164106@rivendell>

On Mar 26, 2012, at 08:03 PM, Andrea Crotti wrote:

>  Should it provide exactly the same command line interface?

Not necessarily.  Looking at the code now I think the long options are
probably fine, but I'm not sure the short options are great (e.g. -o is
usually reserved for output to a file; not relevant for this particular
script, but I don't like appropriating commonly understood options if at all
possible).  Also --unknown won't be useful now; that was a nod to some bug in
MM2.1 we never figured out. ;)  If you make it a bin/mailman subcommand, you
won't need to re-implement -C here.

>- Does it need to be independent from the rest of the code or should
>  it be added to the mailman commands??

I think I would make it a bin/mailman subcommand.  One of the main use cases
for this script is to implement a cron job that site admins can enable to
process users in various statuses.  But I think a cron could invoke a
subcommand just fine.  Still, that use case should inform its cli.

>Anything else that I should know?

One thing to keep in mind is that in mm3, I'm trying to reduce the amount of
logic in the actual commands.  Meaning, it would be better to move as much as
possible into core services, and have the command do as little as possible,
over cli parsing and such.

From davidj at gmail.com  Tue Mar 27 17:53:05 2012
From: davidj at gmail.com (David Jeske)
Date: Tue, 27 Mar 2012 08:53:05 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
	<CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>
Message-ID: <CA+CP9O5DAU3Vb+ec47Q3BL1CxUjA02pUHmRs8Pc=L2qpQ5R_7g@mail.gmail.com>

On Mar 27, 2012 5:32 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> If the archiver/web UI is going to be distributed
> *with* Mailman, Barry would probably prefer
> Storm + Django because that's what
> Mailman/Protorius (core and admin web UI, resp.) are
> using.  But I imagine that's negotiable as long as
> everything is free software.

I'll take a look at the Mailman2/3 code and see what the pattern looks
like.

Storm-ORM looks like it allows any primary key so that's good. From a quick
glance it looks very similar to the Clearsilver-odb-orm in syntax and
function. My primary beef with django-orm (last time I looked at it) was it
requiring a unique-id primary key which is pretty poor for multi-row fetch
performance design.

Clearsilver templating has a slightly more aggressive enforcement of 'no
code in template' than django, because it has an explicit intermediate
dataset called HDF (it doesn't allow access to arbitrary python lists,
structs, classes, and methods). This allows it to work from any language
(not just python), and makes the binding from the ORM a bit more explicit.
However, it also means it's a c-module, and I can see the advantage to
keeping c-compile dependencies to a minimum.

>>> AIUI, the current philosophy is that
>>>
>> Using SMTP for an included archiver would require
>> it be a long running server instead of merely
>> a handler.
>
> Sure, but you're already running a sufficient server,
> namely your MTA.

Gotcha. I thought you were saying Mailman wanted the archiver to be a
long-running server accepting SMTP/LMTP on a socket.

I normally manage the archive queue with the MTA, and have it launch the
archive-injestor for each message.. (or for higher volume applications,
long-running injester on a Maildir).. which sounds like what you're saying..

After I finish some quick cleanup and UI changes to CSLA I want to do, I'll
take a look at MM2/3 and see if I have better questions once I'm informed.

Thanks for the great overview.

From a.badger at gmail.com  Tue Mar 27 20:51:03 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 27 Mar 2012 11:51:03 -0700
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
Message-ID: <20120327185103.GZ11151@unaka.lan>

On Tue, Mar 27, 2012 at 03:01:41PM +0530, Shayan Md wrote:
> 
> 
> On Tue, Mar 27, 2012 at 1:11 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
>     Is this integration to be done with mailman2 or mailman3?
> 
>     In mailman3, the archivers are separated from the mailman core.
> 
> I was working on mm3. But systers' indexer/searcher was implemented for
> mailman2. So it must be easy for to integrate it with mm2.
> 
> Looks like archiver for mm3 is still in development stage. As far as I
> understand searcher depends on the srchiver, right? Not completely but it
> somewhat depends on archiver. I am not sure if searcher can be implemented
> without archiver. If possible I can implement for mm3 also.
> 
The searcher wouldn't be much use without an archiver. There is a sample
archiver in mailman core -- if enabled, it stores the messages to lists in
maildirs.  It does not have a frontend for retrieving or otherwise
displaying the archives.

In some of the other threads here, it was brought up that a builtin archiver
with the same feature set of pipermail could be desirable.  If you're
interested in integrating search into mailman I'd watch (and participate!)
in that thread to see what the outcome of that discussion is.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120327/386222a4/attachment-0001.pgp>

From terri at zone12.com  Tue Mar 27 21:21:21 2012
From: terri at zone12.com (Terri Oda)
Date: Tue, 27 Mar 2012 13:21:21 -0600
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
Message-ID: <4F721331.60807@zone12.com>

On 03/27/2012 03:31 AM, Shayan Md wrote:

> I was working on mm3. But systers' indexer/searcher was implemented for
> mailman2. So it must be easy for to integrate it with mm2.

Actually, the systers indexer was designed to work with mboxes (because 
I had a pile of data in that format that the students could use) but 
otherwise knows pretty much nothing about mailman 2 or 3.  Other than 
handling mbox instead of maildir, which is only a matter of changing 
parsers, it shouldn't matter which it's integrated with. This was a 
design decision at the time, as Mailman 3 was coming but still too 
incomplete to test with when the code was written.

> Looks like archiver for mm3 is still in development stage. As far as I
> understand searcher depends on the srchiver, right? Not completely but it
> somewhat depends on archiver. I am not sure if searcher can be implemented
> without archiver. If possible I can implement for mm3 also.

Searcher and archiver are interdependent *if* we want to share caches 
and data stores, which we probably do for any installation with larger 
archives where storing 2 copies vs 4 of each message would make a 
difference.  Plus, many archive views may be basically searches 
"messages in the last month" "messages which are replies to messageid 
$foo" etc.

Ideally, anyone working on search will interact heavily with the 
archiver and probably usability folk at the beginning so that you can 
figure out what data structures you need to store and index and what use 
cases you'll need to make fast.

  Terri

From alexander at sulfrian.net  Tue Mar 27 21:09:10 2012
From: alexander at sulfrian.net (Alexander Sulfrian)
Date: Tue, 27 Mar 2012 21:09:10 +0200
Subject: [Mailman-Developers] GSoC 2012 - NNTP archive access
Message-ID: <87bonhdfop.wl%alexander@sulfrian.net>

Hi, 

I would like to participate at the google summer of code this year for
mailman. While reading through the ideas in the wiki, the NNTP archive
access look very interesting.

I took part in the gsoc last year for vlc, developing a c library for
accessing a sony minidisc player from linux. This year vlc
unfortunately got rejected from google.

What are the next steps you would propose. I unfortunately not up to
date with the development of mailman 3. But I am a little bit familiar
with the mailman 2 source code.

Thanks,
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120327/7bab7169/attachment.pgp>

From terri at zone12.com  Tue Mar 27 21:29:06 2012
From: terri at zone12.com (Terri Oda)
Date: Tue, 27 Mar 2012 13:29:06 -0600
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
Message-ID: <4F721502.8030902@zone12.com>

On 03/26/2012 11:37 PM, David Jeske wrote:
> CSLA doesn't currently have any concept server-auth. The only stateful
> features it has are view-preferences and read-state, neither of which are
> important enough to require a password. It uses a password-less system
> which uses cookies for prefs and a 'read state userid' which a user can
> manually set if they want. I like it, because it doesn't require login to
> get some basic browsing prefs and features.
>
> Hooking up an auth system would be necessary for some of the editing ideas
> in the document I read, or to allow online posting.

So Postorius (the webUI) has a sketch of an auth system using BrowserID 
at the moment.  BrowserID is convenient 'cause it proves you have 
ownership of a given email address, but we should have OpenID working 
soon once we've got the code to confirm that a given OpenID can be 
associated with an email address.

We should do a little thinking about how to make sure that the archives 
system can make use of the webui authentication.  In theory, you could 
just use the same browserID/etc. and perform authentication again to 
provide a single sign on with the same tokens, but we can probably do 
something nicer by sharing the webui django accounts.

  Terri


From barry at list.org  Tue Mar 27 22:52:04 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 16:52:04 -0400
Subject: [Mailman-Developers] GSoC 2012 - NNTP archive access
In-Reply-To: <87bonhdfop.wl%alexander@sulfrian.net>
References: <87bonhdfop.wl%alexander@sulfrian.net>
Message-ID: <20120327165204.255d7527@resist.wooz.org>

On Mar 27, 2012, at 09:09 PM, Alexander Sulfrian wrote:

>What are the next steps you would propose. I unfortunately not up to
>date with the development of mailman 3. But I am a little bit familiar
>with the mailman 2 source code.

MM3 will be a better platform to build something like the NNTP access on.  The
question in my mind is whether this should be done as part of the various
independent (but related) archiver projects, or whether it should be done as a
separate "archiver".

In mm3, there's an API for feeding posted messages to an IArchiver, but this
is quite flexible.  I could imagine that something on the other end of this
vended messages via NNTP instead of HTTP.  The one key difference is that
you'd like to be able to post to the mailing list through NNTP, with probably
some additional posting rules (e.g. if you're not a member, but we "know" you,
or you've been approved for posting a few times, your message wouldn't get
held for moderator approval).

If I was doing this, I'd probably looks seriously at Twisted as the basis for
implementing the NNTP side of things.  I haven't looked in quite a while, but
at the time, it had great support for NNTP server-side.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120327/6e98bf28/attachment.pgp>

From barry at list.org  Wed Mar 28 00:29:08 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 18:29:08 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
Message-ID: <20120327182908.573b8c96@resist.wooz.org>

On Mar 26, 2012, at 03:20 PM, David Jeske wrote:

>I'm writing to find out the state of and philosophy surrounding pipermail
>in mailman, to see if there is a productive way to provide some
>code/development-time to that part of mailman.

That's awesome.  Pipermail (in its current state) is ancient, and it shows.
It's biggest flaw IMO is the lack of "stable URL" support, meaning if you
regenerate the archive from the underlying mbox file, you'll likely break all
your links.  Pipermail has lots of other problems, but this one for example is
why it was ditched for Launchpad.

I think the time is ripe for new archivers, and Mailman 3's philosophy is to
provide a framework in which developers can easily experiment with new
archiver technology, integrated easily into Mailman.

I personally think it would be best to spend effort on one of the many
archiver projects being worked on, and mentioned here, rather than trying to
improve Pipermail.  One possible connection though would be to consider how a
site would migrate from a Pipermail-based archiver to one of the new ones.  Do
you keep the old URLs alive but just not add anything new to Pipermail?  Do
you provide a mapping from Pipermail URLs to new-archiver URLs?  etc.

>I've written code for this a number of times (eGroups, Yahoo Groups, Google
>Groups). I also released an open-source python/clearsilver/sqlite based
>archiver with redundant text-eliding, a few different thread views, and
>search...  ( http://www.clearsilver.net/archive/ ) which is hardly used
>both because I don't try to popularize it, and because many sites just
>leave the default (pipermail).

Neat.  Perhaps you'd like to contribute an implementation of the IArchiver
interface in Mailman 3 that would send posted messages to ClearSilver?

Here's the current interface definition:

http://tinyurl.com/cup7amw

and some example implementations:

http://tinyurl.com/cynyfou

>a) pipermail is fine... if you want to fix a bug or two submit a patch, but
>we don't want to improve it

Note that before I ripped Pipermail out of the Mailman 3 trunk branch, I
created a project on Launchpad and pushed a semi-sanitized branch:

https://code.launchpad.net/pipermail

I don't personally plan to touch this, but if someone is really motivated to
hack on Pipermail specifically, I'd happily give you access.

>b) we're ditching pipermail entirely... in the future sites will have to
>choose an install an external archiver

Yes, but remember, you can choose one or more archivers in Mailman 3.  So it
would be easy to archive to something local, and The Mail Archive, and Gmane,
etc.

>c) we'd love pipermail to be improved... but we still want it to be simple,
>static-html, and dependency free
>d) we'd love a dynamic-ui replacement for pipermail... as long as it uses
>the same cgi/templating model as mailman ui

Because Postorius (the official, but not required MM3 web ui) is Django-based,
I think it should be pretty flexible for customizing the look and feel.  I
won't dictate what a new archiver should look like, but some principles that I
personally think should be followed include:

- Modern web technologies, with flexible templating, so that sites can
  customize the look and feel as needed.

- JavaScript not required: an archiver should be navigable with a text-based
  simple browser, but that also doesn't mean it has to be feature-equivalent
  if you *do* have JavaScript.  I think "progressive enhancement" is the right
  term?  I.e. make it awesome for today's web, but usable in older browsers,
  screen readers (for accessibility), etc.

- Dynamic generation of pages with caching.  I'd love to see an enhanceable
  approach to the actual HTML generation.  Let's say for example, that I
  suddenly want to recognize and hyperlink "bug numbers" so they point to my
  tracker.  I should be able to drop in some extension to do that.  Or maybe
  the spammers have cracked my email obfuscation algorithm.  I should be able
  to drop in a replacement, invalidate the cache, and all my new page would
  automatically get the new obfuscation algorithm.

- Separate, dynamic support for take down notices.  You posted your personal
  information and have asked the site's postmasters to take that down (either
  the full message or the personal information parts of it).  It should be
  really simple for the site admins to do this, while possibly retaining the
  original message in a publicly inaccessible location for forensic purposes.

- Support for private archivers, so configurable authentication would be
  necessary.

- Merging of forums, archives, newsgroups, and IMAP.

- A REST API for querying information about the site, its lists, individual
  archived messages, metrics, etc.  Maybe even some control (e.g. take downs)
  for users with the proper permissions.

- Stable URLs, RFC 5064 + X-Message-ID-Hash.  See the above links.  If you can
  implement the `IArchiver.permalink()` method and ensure that even if
  completely wiped and regenerated from the underlying raw messages, your URLs
  will remain stable, I think you will have won. :)

That's about all I can think of right now, but I'll say this: I think there's
huge untapped value in a really great archiving framework.  I have lots of
ideas and it's something I'd like to work on eventually, once we get the core
engine stable and released.

Also, as you work on archivers and try to integrate them with mm3, please do
provide feedback on the IArchiver API and the integration implementation in
particular.  What's missing?  What's wrong with the API?

Note too that atm, the lp:mailman bzr trunk is a bit ahead of 3.0b1 here.  I
had to disable some things at the last minute in the ArchiveRunner, and I've
since fixed and pushed updates.  So you probably want to at least take a look
at the bzr branch.

Cheers,
-Barry


From jeff at jab.org  Wed Mar 28 02:20:18 2012
From: jeff at jab.org (Jeff Breidenbach)
Date: Tue, 27 Mar 2012 17:20:18 -0700
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
 andPostorius 1.0 alpha 1
In-Reply-To: <PC195201203251548530765aee868f2@MSAPIRO>
References: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<PC195201203251548530765aee868f2@MSAPIRO>
Message-ID: <CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>

What is the incantation for enabling an external archiving service?
Currently I only see this in mailman.cfg after following 5 minute guide.

[runner.archive]
class: mailman.runners.archive.ArchiveRunner

> archivers are configured site-wide, so there's almost nothing
> to expose in the web-ui.

I'm worried about confusion. The last thing we want is for a list to be
accidentally archived contrary to the list administrator's wish. It sounds
scary to me not to have any indication whatsoever in the web
interface.

Along similar lines, there seems opportunity for confusion if there are
two independent mechanisms for archival; site wide configuration and
also manually subscribing an archival subscriber such as
archive at mail-archive.com. I can imagine someone turning off just
one of these two mechanisms then being surprised that it had
no practical effect.

Finally, it sounds like there are architectural reasons for having
archiving a site-wide configuration. But I do think list admins would
appreciate some sort per list GUI option, to easily distinguish
between public and private lists. These are often different folks
from the sysadmin who can apt-get install mailman without
giving a first glance at the mailman.cfg file.

-Jeff

From stephen at xemacs.org  Wed Mar 28 03:29:45 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 28 Mar 2012 10:29:45 +0900
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <4F721331.60807@zone12.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
Message-ID: <CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>

On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda <terri at zone12.com> wrote:

>> Looks like archiver for mm3 is still in development stage. As far as I
>> understand searcher depends on the srchiver, right? Not completely but it
>> somewhat depends on archiver. I am not sure if searcher can be implemented
>> without archiver. If possible I can implement for mm3 also.
>
> Searcher and archiver are interdependent *if* we want to share caches and
> data stores, which we probably do for any installation with larger archives
> where storing 2 copies vs 4 of each message would make a difference. ?Plus,
> many archive views may be basically searches "messages in the last month"
> "messages which are replies to messageid $foo" etc.

Actually, as far as I can see, the summary/search/index/retrieval
functions depend only on the API for the message store.  If you
want, you can split this into the database layer and a presentation
layer, of course.  However, the database layer is surely going to
have its own schema optimized for the kinds of retrieval its
designer considers important.  If the designer emphasizes
threads, however, she is *not* going to try to store messages in
thread order or anything like that.  Rather, any reasonable store
will be message-ID-addressable.

The only tricky issue is that we *do* have to worry about
message-ID collisions of truly different messages and about
messages without message IDs, especially for converted
historical archives.  So the API needs to be able to deal
with these issues, probably by returning a set or sequence
of messages.

Oh, and we probably ought to have a more general notion
of retrievable "object" rather than just messages, as some
archive/retrieval backends may store some types of MIME
part separately.  Hopefully these would be presented to
us as MIME parts with external bodies and content IDs.

I would guess she'll probably store messages in
YY-MM/MSGID, or as git does in "unpacked"
XX/YYYYYYYY... format, where XX are the first two digits
of the hash ID, and YY... are the remaining ones).  But it
could easily be backed by an IMAP store or something
more specialized; we don't really care as long as it's
object-ID-addressable.

And that's all we want to say about the archiver and the
associated message-retrieval logic, I think.  (In fact, it occurs to
me that maybe we should say "RFC 3501" and be done with
it.  I don't mean that we necessarily implement IMAP protocol
per se, but some subset of its functionality probably is what we
need from an archiver.)

Then the schema-specific stuff will use hash IDs to represent
message objects in a portable but schema-specific way.  As
it's schema-specific, I don't really see how data structures
can be shared by different searchers.

So I would say not to worry about the archiver side at all.  If
large installations want to implement specialized message-
retrieval, bully for them.  But we can go with simple backends,
maildir, mbox, and maybe IMAP, I think.

From barry at list.org  Wed Mar 28 04:38:20 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 22:38:20 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
Message-ID: <20120327223820.6715463d@resist.wooz.org>

On Mar 27, 2012, at 10:34 AM, Stephen J. Turnbull wrote:

>Pipermail is going the way of the dodo, yes, but there will be something
>bundled with Mailman, I'm pretty sure.

fsvo "bundled" :)

>(1) the communication from Mailman to the archivers will be via
>LMTP/SMTP, including a Mailman-specific header to identify the
>message's permalink (currently the SHA1 hash of the message ID
>in BASE32 format, IIRC); and

Kind of.  Communication *into* Mailman is via LMTP, but sending a message out
of mm3 into the archiver can be hidden behind the IArchiver interface.  The
prototype archiver, just opens a maildir and adds the new message to that.
The mailarchive implementation drops the message into the outgoing queue, but
with a recipient as specified in the configuration file.  The mhonarc archiver
calls a subprocess and pipes the message's bytes to that process's stdin.  The
moral is that whatever you need to do to get the message into the archiver,
you can do it.

You're right about the algorithm for calculating the X-Message-Id-Hash.  Full
details are on the wiki.  The intent here is to be able to calculate the URL
to the message in the archiver without actually having to communicate with the
archiver.

>(2) the summary, search, and retrieval UI will be a separate
>application from Mailman per se, which will communicate
>with Mailman via the REST API for authentication and user
>configuration purposes.

Yep.

I've also been thinking; we have an IMessageStore interface which currently
isn't much hooked up in any way.  It's possible that a specific archiver could
satisfy the IMessageStore API as well, and that eventually we could implement
things like a mail command that, given a Message-ID (or its hash) would send
you back the message from the store.

>Some ideas that have *not* been elaborated as "philosophy", but
>which I think are consistent with various desiderata and Barry's
>general approach and specific statements are
>
>(3) an archiver Handler for the pipeline will be provided, which
>will store posts in maildir format and do nothing else; and

I've been thinking that the prototype archiver could be this thing.  Well, it
already essentially *is* that thing!  So, it's not in a handler, but gets
invoked from the ArchiveRunner.

>(4) a simple default summary/search/retrieval application will
>be bundled with (but have a separate development cycle from)
>Mailman.

+1

>Even if that's not the current philosophy <wink/> that's the
>direction I would propose.
>
>So if you have already developed some stuff, I certainly would
>love to see you put it on the table as a candidate for the
>Mailman 3 default archive web UI.

Definitely.

My intent with mm3 is to provide an enabling platform for archiver
developers.  I think there's lots of opportunity for experimentation here, so
let's make sure we get the API between mm3 and a generic archiver right.
We'll see what pans out and then we can choose a preferred default that we can
bless and bundle in some kind of sumo release.

Cheers,
-Barry

From barry at list.org  Wed Mar 28 04:53:19 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 22:53:19 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
Message-ID: <20120327225319.37455384@resist.wooz.org>

On Mar 26, 2012, at 10:37 PM, David Jeske wrote:

>Yes. My CSLA code is on the table for MM2 or 3. It's python, and it's BSD.
>More than that, if you folks want it, I'm happy to retool/rewrite it as
>needed to make it suitable. (it has lots of great features, but i havn't
>touched it in a long time and it could be better) I'll put up a demo of the
>mailman list in CSLA tomorrow so folks can check it out.
>
>I also have "some experience" with this space, and by that I mean
>mountainous-experience. I coded/managed/architected several versions of
>eGroups/Yahoo Groups and Google Groups, including the listprocessor, schema
>design, and a few different python mail-to-html formatters. I also wrote my
>own personal gmail-like web-mailer in python, which someday I'll get around
>to open-sourcing.

See, stuff like this is *awesome*.

>Can you share something about dependency philosophy (besides licensing) in
>Mailman?

I really want to promote loose dependencies between major components, with
well-defined formal interfaces for them to interoperate.  Think "service
oriented architecture".  Unlike mm2, which tightly bundled the web ui and
archiver with the core engine, I think we can split these out into separate
components and yet ensure they'll all work together nicely.  Then we can
decide what might fall under the "GNU Mailman" umbrella, what will be our
default services, how we're going to bundle and release them, etc.  But others
will be able to make their own choices.

>Currently CSLA uses Clearsilver templating (BSD c-module) and sqlite
>(public domain) storage.. both of which can be included directly as source
>to make installation easy, but they are both c-modules.
>
>I'm quite fond of the Clearsilver orm-to-templates toolchain, which is in
>use for lots of big sites. However, I also recognize it's not that popular
>in the python commmunity, mostly because we don't promote it, but also
>because the template processor c-module (for performance) instead of pure
>python.

In a way, it's like the Python library ecosystem.  Most third party libraries
are independently developed and released, but pretty much work with (a
specific version of) Python.  Occasionally, some are borged into the Python
stdlib, which is both a blessing and a curse.

So in some sense, CSLA needn't become *the* Mailman archiver, but it should
definitely be *a* Mailman archiver.  Then you can make all the engineering and
design decisions you prefer, but with the confidence that it will Just Work
with Mailman 3.

(This of course also means you don't have to worry about boring stuff like
licensing, FSF copyright assignments, etc. etc.)

>Using SMTP for an included archiver would require it be a long running
>server instead of merely a handler.
>
>Are we talking about third-party-site archivers here?

In some sense, yes.  Eventually, something will percolate to the top, have
technological decisions that we're comfortable with maintaining, compatible
licensing, etc. and then we can bring it under the Mailman umbrella.  But hey,
don't wait for that!  Make it work with the mm3 engine now and release early
and often.

(I clarified in a previous message that SMTP into the archiver is not a
requirement.  The implementation should be flexible enough to handle just
about any input mechanism you need.)

>CSLA doesn't currently have any concept server-auth. The only stateful
>features it has are view-preferences and read-state, neither of which are
>important enough to require a password. It uses a password-less system
>which uses cookies for prefs and a 'read state userid' which a user can
>manually set if they want. I like it, because it doesn't require login to
>get some basic browsing prefs and features.
>
>Hooking up an auth system would be necessary for some of the editing ideas
>in the document I read, or to allow online posting.

Or to support private archives, which is very definitely a feature goal IMO.
Even a 99% public site will likely have a few closed or limited access lists,
so I think an archiver will need to support use case.

-Barry


From barry at list.org  Wed Mar 28 04:55:20 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 22:55:20 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <4F721502.8030902@zone12.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
	<4F721502.8030902@zone12.com>
Message-ID: <20120327225520.7759c4fb@resist.wooz.org>

On Mar 27, 2012, at 01:29 PM, Terri Oda wrote:

>So Postorius (the webUI) has a sketch of an auth system using BrowserID at
>the moment.  BrowserID is convenient 'cause it proves you have ownership of a
>given email address, but we should have OpenID working soon once we've got
>the code to confirm that a given OpenID can be associated with an email
>address.
>
>We should do a little thinking about how to make sure that the archives
>system can make use of the webui authentication.  In theory, you could just
>use the same browserID/etc. and perform authentication again to provide a
>single sign on with the same tokens, but we can probably do something nicer
>by sharing the webui django accounts.

Definitely.

One thing the engine has to expose is the ability to associate multiple email
addresses with a "user".  The core supports this as a concept, but we may not
have what we need exposed in the REST API yet.  It's also something I want to
expose in the email commands interface.

-Barry

From barry at list.org  Wed Mar 28 05:07:02 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 23:07:02 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
	<CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>
Message-ID: <20120327230702.29e30fa9@resist.wooz.org>

On Mar 27, 2012, at 09:32 PM, Stephen J. Turnbull wrote:

>Well, for the official poop you'll have to wait for Barry, but AFAICS
>archivers aren't restricted to Storm + RESTish (which is what Mailman itself
>uses) because they're separate applications.  If the archiver/web UI is going
>to be distributed *with* Mailman, Barry would probably prefer Storm + Django
>because that's what Mailman/Protorius (core and admin web UI, resp.) are
>using.  But I imagine that's negotiable as long as everything is free
>software.
>
>I don't think the database backend much matters, but Mailman and Django
>are both happy to use sqlite, I believe.

What Stephen says above is pretty accurate.  See also my previous follow ups
in this thread.

The core engine uses Storm as its ORM, which I think officially supports
SQLite, PostgreSQL, and MySQL, though it's probably compatible with others out
of the box or easily so.

Mailman itself currently only supports SQLite out of the box because that
comes with Python, and we have donated support for PostgreSQL.  I'd love for
someone to donate MySQL support; I think it would be easy for someone with
MySQL experience, there isn't much that would need to be added to Mailman,
there are good examples now, and I would of course be happy to help.

The biggest problem with multiple database support is ensuring we're getting
good testing with them.  I do almost all my tests with SQLite and we don't
have a buildbot/jenkins farm yet to test all combinations (and Python 2.6/2.7
:).

>> I'm not a fan of javascript client-side rendering because of the generally
>> poor performance, poor mobile compatibility, and lack of benefit for this
>> kind of application.
>
>Not my pidgin, you'll need to talk to Toshio/Barry about that.
>>> AIUI, the current philosophy is that

As a third party archiver, I can't tell you what to do, but my personal
preference would be that JS is fine if it enhances the user experience, but
that it be possible to perform basic archiver interactions without it.

Cheers,
-Barry

From barry at list.org  Wed Mar 28 05:21:45 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 23:21:45 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O5DAU3Vb+ec47Q3BL1CxUjA02pUHmRs8Pc=L2qpQ5R_7g@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<CAL_0O19DZx0+RJeqMpCh1y8=64=G2Z6SWCWQ8YGah_QWN6Q78A@mail.gmail.com>
	<CA+CP9O7V6ww7U7H=2tnTezrJbN=ZL4tAQP7DCnoLm43i_AS2fw@mail.gmail.com>
	<CAL_0O19STCmB0X32FCO80KWKJtCv=cRji05tMKG1V6GjTvYDQg@mail.gmail.com>
	<CA+CP9O5DAU3Vb+ec47Q3BL1CxUjA02pUHmRs8Pc=L2qpQ5R_7g@mail.gmail.com>
Message-ID: <20120327232145.5e6d3df6@resist.wooz.org>

On Mar 27, 2012, at 08:53 AM, David Jeske wrote:

>Storm-ORM looks like it allows any primary key so that's good. From a quick
>glance it looks very similar to the Clearsilver-odb-orm in syntax and
>function. My primary beef with django-orm (last time I looked at it) was it
>requiring a unique-id primary key which is pretty poor for multi-row fetch
>performance design.

Here's my take on ORMs.

Early on mm3 went through phases with both SQLObject and SQLAlchemy, which I'd
say are the other two most popular Python ORMs that aren't specifically tied
to a CMS.  It's been a few years now, but both had lots of problems that
manifested as unacceptably slow velocity for making changes to Mailman.

What I like about Storm is that it's so lightweight.  When something goes
wrong (e.g. not being able to store flufl.enum.Enums in the database or UTC
timezone-aware datetimes into SQLite), I've always found it pretty trivial to
dig into Storm, find the problem, maybe fix it, or at least easily work around
it.  The well-written, thin-ish layer of Python code makes up for the lack of
comprehensive documentation.  UTSL.

Storm is also heavily used within Canonical so I know who to beg with or
scream at if I need something :).  Seriously though, it powers Launchpad among
other tech, so it's pretty well battle-tested.

But I'm the first to admit I'm not a database expert, so while I can make
stuff work in Storm, it may not be optimal.  Two examples: I've gotten
donations to make some of the queries more efficient and I'll always welcome
those types of contributions.  Second, I know that some of the constraints I
have expressed in the SQLite schema can't be expressed in a more strict
database such as PostgreSQL.  It would be nice for someone to dig in and fix
those.

The other thing to keep in mind is that within the core, I've tried very hard
to again, use formal interfaces between components so that it could almost not
matter.  This hasn't been field tested so maybe I failed, but the idea is that
you could potentially rip out the model and database layers and provide
alternative implementations of IDatabase and other interfaces, and the rest of
Mailman should Just Work.  I try to be very careful not to break those
abstractions, and I think the Zope Component Architecture is the big win
here.

>Clearsilver templating has a slightly more aggressive enforcement of 'no
>code in template' than django, because it has an explicit intermediate
>dataset called HDF (it doesn't allow access to arbitrary python lists,
>structs, classes, and methods). This allows it to work from any language
>(not just python), and makes the binding from the ORM a bit more explicit.
>However, it also means it's a c-module, and I can see the advantage to
>keeping c-compile dependencies to a minimum.

While I want to keep the Mailman core as pure Python, and so far have seen no
reason to think it can't be, we already have some C dependencies in our
stack.  Some of the libraries that Mailman depends on have C extensions that
are either required or improve performance.  This already means that to deploy
a mm3 server you currently need a C compiler (and the "development" bit of
Python, e.g. Python.h).

Now, eventually you'll probably get this all from your distro, so won't have
to worry about it, but that's the state of affairs atm.

>After I finish some quick cleanup and UI changes to CSLA I want to do, I'll
>take a look at MM2/3 and see if I have better questions once I'm informed.

mm2 and mm3 will differ greatly in the parts you're going to care about.  My
suggestion is to forget about mm2 and concentrate on mm3.

Cheers,
-Barry


From barry at list.org  Wed Mar 28 05:29:10 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 23:29:10 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327001152.GY11151@unaka.lan>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
Message-ID: <20120327232910.64c0d420@resist.wooz.org>

On Mar 26, 2012, at 05:11 PM, Toshio Kuratomi wrote:

>We'd love to have work done on the archier!  I know that we're ditching
>pipermail entirely and that archivers are becoming separate from the core
>mailman.  What I don't know is whether mailman3 will eventually have
>a standard archiver which lives outside of the core mailman but is
>recommended for installation along with it.

Yeah, who knows? :)

>At PyCon a few weeks ago, I demoed hyperkitty which showed some of the
>things that a next generation archiver could do.  hyperkitty is continuing
>to be developed.  As I was talking about hyperkitty we touched briefly on
>what I think is one of the central conundrums about having only unofficial
>third party archivers:  how to have a consistent programatic interface
>available over http.  Grackle is another archiver for mailman that doesn't
>have the UI bells and whistles of hyperkitty but it does make an effort to
>expose a REST UI to the world.  I think that's a beautiful thing.  But
>I don't like that a site that wanted both would need to run two archivers
>that were saving mail into two sets of storage.

Really excellent points Toshio.

>I think there's several ways we could go about this.
>
>* We could create a standard REST API that archivers were free but
>  encouraged  to implement.
>* We could expand the python API that archivers needed to expose and then
>  implement the REST API inside of mailman Core (or a re-envisioned,
>  lightweight Grackle).
>* We could promote a standard archiver much as we're going to promote
>  posterius as the standard admin front-end and that archiver would provide
>  a standard REST API that others could then emulate.

And very good suggestions too.  I'm not sure what the best thing to do right
now, but I've long thought that the core needs a basic "message store" (as
you'll see in the IMessageStore interface, which probably sucks ;).  It's
possible that the prototype archiver morphs into this thing and that as we
expose the IMessageStore to the core's REST API, we'll start to define what we
need from an archiver.  I agree that having such an API in front of the
archiver is a truly beautiful thing.

>(One thing I notice about grackle now is that it's AGPL... that's going to
>be unpleasant for some sites to run.  Perhaps we can change that or get some
>changes added to the AGPL.)

It may be difficult to change.  Canonical's default license on FLOSS it
releases is AGPL.  If we can make a good case for wanting something different,
it may be possible to change.  On a separate track, at Pycon you made a
persuasive argument about the AGPL's flaws, and since that's an official FSF
license, it would be good if "someone" would explore addressing those problems
with them.  That probably won't be me <wink>.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120327/eb29cb6b/attachment.pgp>

From barry at list.org  Wed Mar 28 05:46:49 2012
From: barry at list.org (Barry Warsaw)
Date: Tue, 27 Mar 2012 23:46:49 -0400
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O7Jvg-1EvGUuQ5jJHXWD+AcuEM0rrGxVDu7XCZrJpnNLA@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
	<CA+CP9O7Jvg-1EvGUuQ5jJHXWD+AcuEM0rrGxVDu7XCZrJpnNLA@mail.gmail.com>
Message-ID: <20120327234649.74f034ea@resist.wooz.org>

On Mar 26, 2012, at 06:07 PM, David Jeske wrote:

>I highly recommend reconsidering this and including a standard archiver
>with mailman. If the number of sites that use pipermail is any indication,
>I think failing to include something will basically mean lots of lists
>without any archives.

I think you're right.  People want a turnkey solution - download one thing,
run one command, and you've got everything you need.  Of course, with mm2, you
*don't* though because Pipermail never provided searching for example.

There are lots of questions to ask about how we in the Mailman project would
provide that kind of turnkey solution that includes our best-of-breed
services.  OTOH, it's also powerful to provide choice and not require any
specific bits.

My gut tells me that we're on the right track with Postorius, but that we're
pretty far away from being able to bless an archiver right now.  It's
definitely not something I want to hold up the 3.0 final release for, so we
have to find the right way to manage our users expectations.

Understand though that we're constrained in other ways when we start thinking
about bundling or officially blessing certain components.  Mailman is a GNU
project and the core's copyright has been owned by the FSF for over a decade.
We require copyright assignments to the FSF.  Postorius falls under the same
administrative structure, so there's no problem calling it the official GNU
Mailman web ui.  A bless, bundled archiver will have to probably adhere to the
same constraints, or at least we'd have to have that conversation with the FSF
about it.

But that absolutely shouldn't stop any other third party archiver from being
Mailman 3 compatible.

As I said, like the Python standard library, it's both a blessing and a
curse. :)

>As for the features it doesn't have from your list: Editing would be easy
>to add because it's sqlite (deciding on the auth system is probably more of
>an issue than the editing). Anti-Crawl code is really an issue of
>configuration for cheap in-memory state-management. NNTP is well. that
>would be a big job that I doubt will be bitten off by something as "small"
>as a list archiver.

Why can't we kill off Gmane while we're killing off Gmail, and *Groups? :).

>What is the REST UI used by? CSLA supports RSS. When it comes to a more
>involved REST UI, what software would be hitting it? I don't think I'll
>understand your other API/REST points until I see an answer to this.

I'm a list owner and someone requests that a post containing private
information be taken down.

As a drive-by archive user, I want to request that a message get sent to me so
that I can reply to it in my mail reader as if I had received the original.

I run a question/answer forum that gateways a list, and I want to +1 really
helpful messages, or give some extra kudos to really helpful users.

-Barry

From stephen at xemacs.org  Wed Mar 28 06:54:14 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 28 Mar 2012 13:54:14 +0900
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
 andPostorius 1.0 alpha 1
In-Reply-To: <CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
References: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<PC195201203251548530765aee868f2@MSAPIRO>
	<CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
Message-ID: <CAL_0O18i8qQ8rvVhPcPZPVbYr3dJY_Lsng-0NUUXhE72cEoRAQ@mail.gmail.com>

On Wed, Mar 28, 2012 at 9:20 AM, Jeff Breidenbach <jeff at jab.org> wrote:

>> archivers are configured site-wide, so there's almost nothing
>> to expose in the web-ui.
>
> I'm worried about confusion.

Indeed.  I think Barry misspoke here.  But remember, we're barely out
of alpha test, and we don't actually have a standard archiver, just a
simple handler to support further development.

> The last thing we want is for a list to be
> accidentally archived contrary to the list administrator's wish. It sounds
> scary to me not to have any indication whatsoever in the web
> interface.

However, this is unavoidable, since in an open-subscription or
confirm-only list anybody can request Gmane or mail-archive.com to
subscribe, and of course users will save their mail in many cases.

I think it's arguable that it's best to archive everything (eg, so you
can demonstrate that a particular piece of spam did or did not come
through your list), and lock it down at the archive-viewer level.

> Along similar lines, there seems opportunity for confusion if there are
> two independent mechanisms for archival; site wide configuration and
> also manually subscribing an archival subscriber

Personally, I think only the latter should be provided by default
since it can't easily be prevented unless the list owner vets all
subscribers very carefully (including having access to their
.forwards!)  Of course individual sites or lists can provide their own
archiving handlers, and for the purpose of developing archivers and
archive browsers offline, it may be useful to have a simple
archive-to-maildir handler.  (Note that the usual MTA/MDA suites can
be used to deliver to maildirs, so for a list that's actually online,
to get a local archive you just set up a $LIST-archiver virtual user
delivering to maildir.  AFAICS, this will be sufficiently efficient.)

From barry at list.org  Wed Mar 28 17:11:43 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 11:11:43 -0400
Subject: [Mailman-Developers] [Question #191915]: unsubscription from
 conversations in Mailman
In-Reply-To: <20120328083557.18579.14700.launchpad@loganberry.canonical.com>
References: <20120328083557.18579.14700.launchpad@loganberry.canonical.com>
Message-ID: <20120328111143.3f3b92c6@resist.wooz.org>

On Mar 28, 2012, at 08:35 AM, Bhavya PH wrote:

>New question #191915 on mailman in Ubuntu:
>https://answers.launchpad.net/ubuntu/+source/mailman/+question/191915
>
>I have looked through the release notes of Mailman3.0 and can find
>documentation only on a user subscribing, unsubscribing to mailing lists
>using REST ful API, but I am a little confused about how users are
>unsubscribed from conversations ? Can someone point me to that part of the
>documentation?

This feature does not yet exist in Mailman 3.

-Barry


From odhiambo at gmail.com  Wed Mar 28 17:13:52 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Wed, 28 Mar 2012 18:13:52 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
Message-ID: <CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>

On Mon, Mar 26, 2012 at 00:34, Jeff Breidenbach <jeff at jab.org> wrote:

> Congratulations! I was able to get Postorius running by following the
> five minute quick start guide. I didn't see archiving settings in the
> user interface, how do I set that up?
>
>

Hey Jeff and all,

I followed the "five minute guide", but I am hitting a brickwall:

[root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python
manage.py syncdb
Traceback (most recent call last):
  File "manage.py", line 29, in <module>
    execute_manager(settings)
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
line 459, in execute_manager
    utility.execute()
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
line 232, in execute
    output = self.handle(*args, **options)
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
line 371, in handle
    return self.handle_noargs(**options)
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py",
line 57, in handle_noargs
    cursor = connection.cursor()
  File
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py",
line 15, in complain
    raise ImproperlyConfigured("settings.DATABASES is improperly
configured. "
django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
improperly configured. Please supply the ENGINE value. Check settings
documentation for more details.


Can anyone tell what I am doing wrong?


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/732e2c61/attachment.png>

From barry at list.org  Wed Mar 28 17:53:24 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 11:53:24 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
 andPostorius 1.0 alpha 1
In-Reply-To: <CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
References: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<PC195201203251548530765aee868f2@MSAPIRO>
	<CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
Message-ID: <20120328115324.6ddfccd0@rivendell>

On Mar 27, 2012, at 05:20 PM, Jeff Breidenbach wrote:

>What is the incantation for enabling an external archiving service?
>Currently I only see this in mailman.cfg after following 5 minute guide.
>
>[runner.archive]
>class: mailman.runners.archive.ArchiveRunner

That configuration variable just sets up the appropriate queue runner.  Of
course without that, nothing would get archived, but it's not the interesting
bit from your perspective. :)

(I know that figuring out the configuration ini-file stack can be a little
confusing; we need better/more docs!)

So, every archiver that Mailman knows about will have a section such as

[archiver.<name>]

where <name> can currently be mhonarc, mail_archive, or prototype.  It
shouldn't be difficult to add new archivers by doing something like this in
your mailman.cfg file:

[archiver.hyperkitty]
class: sys.path.to.my.module.HyperKittyClass
enable: yes

It's the 'enable' variable that defines whether the archiver is enabled
system-wide or not.  This is documented in schema.cfg (think: the bottom rung
of the ini-stack, although it's slightly different than mailman.cfg).

(Aside: I think I need to start a YouTube channel on mm3 :).

The template for archiver sections is the [archiver.master] section in the
schema.cfg.  You'll see all the standard configuration variables defined
there, with their default values.

These are all site-wide configurations which define, enable, and configure the
various archivers available to the system.

Mailing lists themselves have a more limited palette (currently) for
configuring their archiving behavior.  There are two list-specific values:

 - IMailingList.archive is a boolean which determines whether the list will
   archive its messages at all or not.  The default list style sets this to
   true.

 - IMailingList.archive_private is a boolean only consulted in the
   mail_archive archiver.  If this is true, then it will not email messages to
   that service.

I've thought about giving more control to individual lists, but I'm not sure
how much value there is in allowing a list owner to e.g. decide which of the
set of enabled archivers their messages get forwarded to.

>> archivers are configured site-wide, so there's almost nothing
>> to expose in the web-ui.
>
>I'm worried about confusion. The last thing we want is for a list to be
>accidentally archived contrary to the list administrator's wish. It sounds
>scary to me not to have any indication whatsoever in the web
>interface.

Ah, sorry, yes the two booleans above should be exposed in the REST API.

https://bugs.launchpad.net/mailman/+bug/967238

I've marked it 'easy' and I think it would be.

I'm not sure whether you're asking if the ini-file settings should be exposed
in the REST API.  I'm much less certain about that.  I think it wouldn't be
difficult to expose them read-only, but I'm hesitant to let REST clients
change mailman.cfg variables, especially because having them take effect would
require a restart.

>Along similar lines, there seems opportunity for confusion if there are
>two independent mechanisms for archival; site wide configuration and
>also manually subscribing an archival subscriber such as
>archive at mail-archive.com. I can imagine someone turning off just
>one of these two mechanisms then being surprised that it had
>no practical effect.

Hopefully the above explains things.  The mail-archive implementation of
IArchiver does just email the address specified in
[archiver.mail_archive]recipient, but it won't do this if the mailing list's
.archive_private setting is True.

Suggestions for better integration are welcome.

>Finally, it sounds like there are architectural reasons for having
>archiving a site-wide configuration. But I do think list admins would
>appreciate some sort per list GUI option, to easily distinguish
>between public and private lists. These are often different folks
>from the sysadmin who can apt-get install mailman without
>giving a first glance at the mailman.cfg file.

Hopefully the above explains the state of things.  The system needs to know
about all the available archivers, but list admins do have some small amount
of control over whether their list gets archived or not.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/fe5d5515/attachment.pgp>

From barry at list.org  Wed Mar 28 17:59:27 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 11:59:27 -0400
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
 andPostorius 1.0 alpha 1
In-Reply-To: <CAL_0O18i8qQ8rvVhPcPZPVbYr3dJY_Lsng-0NUUXhE72cEoRAQ@mail.gmail.com>
References: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<PC195201203251548530765aee868f2@MSAPIRO>
	<CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
	<CAL_0O18i8qQ8rvVhPcPZPVbYr3dJY_Lsng-0NUUXhE72cEoRAQ@mail.gmail.com>
Message-ID: <20120328115927.55495559@rivendell>

On Mar 28, 2012, at 01:54 PM, Stephen J. Turnbull wrote:

>Indeed.  I think Barry misspoke here.  But remember, we're barely out
>of alpha test, and we don't actually have a standard archiver, just a
>simple handler to support further development.

I just want to be careful about terminology here.  "Handlers" specifically are
modules that are invoked during pipeline processing.  There's a 'to-archive'
handler but all that does is put a copy of the message and metadata into the
archive queue.

There are also implementations of the IArchiver interface, which is where the
actual work of getting the message injected into the archiver happens.
Implementations are free to do whatever they want here, and in fact you'll see
wide variety in the existing ones (send to an address, call a subproc, drop a
file in a maildir).

The archive queue runner is what loops over the available and enabled
IArchiver implementations.  So it goes something like:

pipeline queue runner --to-archive-> archive queue runner --IArchivers--+
                        handler                           ^-------------|

Cheers,
-Barry

From f at state-of-mind.de  Wed Mar 28 18:13:49 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Wed, 28 Mar 2012 18:13:49 +0200
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
Message-ID: <4F7338BD.70501@state-of-mind.de>

Hi Odhiambo,

Am 28.03.12 17:13, schrieb Odhiambo Washington:
> Hey Jeff and all,
> 
> I followed the "five minute guide", but I am hitting a brickwall:
> 
> [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python
> manage.py syncdb
> Traceback (most recent call last):
>   File "manage.py", line 29, in <module>
>     execute_manager(settings)
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
> line 459, in execute_manager
>     utility.execute()
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
> line 382, in execute
>     self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> line 196, in run_from_argv
>     self.execute(*args, **options.__dict__)
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> line 232, in execute
>     output = self.handle(*args, **options)
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> line 371, in handle
>     return self.handle_noargs(**options)
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py",
> line 57, in handle_noargs
>     cursor = connection.cursor()
>   File
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py",
> line 15, in complain
>     raise ImproperlyConfigured("settings.DATABASES is improperly
> configured. "
> django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
> improperly configured. Please supply the ENGINE value. Check settings
> documentation for more details.

You're doing nothing wrong! Except you're using the latest Django
version (1.4) which was released only some days ago... :-)

In Django 1.2 support for multiple databases has been added, so they
extended the format of the db definition in settings.py. It looks like
in 1.4 the old format (which we have used so far) is no longer supported
which most definitely causes the above error to be thrown.

Changing the DATABASE setting in dev_setup/settings.py should do the
trick. Like here:
https://docs.djangoproject.com/en/1.4/ref/settings/#databases

I will fix that in our launchpad branch as well, so these changes will
go into the next alpha (which will probably be released not too far from
now... :-)

Florian




> 
> 
> Can anyone tell what I am doing wrong?
> 
> 
> 
> 
> 
> _______________________________________________
> 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 odhiambo at gmail.com  Wed Mar 28 18:40:08 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Wed, 28 Mar 2012 19:40:08 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F7338BD.70501@state-of-mind.de>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
Message-ID: <CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>

On Wed, Mar 28, 2012 at 19:13, Florian Fuchs <f at state-of-mind.de> wrote:

> Hi Odhiambo,
>
> Am 28.03.12 17:13, schrieb Odhiambo Washington:
> > Hey Jeff and all,
> >
> > I followed the "five minute guide", but I am hitting a brickwall:
> >
> > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
> python
> > manage.py syncdb
> > Traceback (most recent call last):
> >   File "manage.py", line 29, in <module>
> >     execute_manager(settings)
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
> > line 459, in execute_manager
> >     utility.execute()
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
> > line 382, in execute
> >     self.fetch_command(subcommand).run_from_argv(self.argv)
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> > line 196, in run_from_argv
> >     self.execute(*args, **options.__dict__)
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> > line 232, in execute
> >     output = self.handle(*args, **options)
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
> > line 371, in handle
> >     return self.handle_noargs(**options)
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py",
> > line 57, in handle_noargs
> >     cursor = connection.cursor()
> >   File
> >
> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py",
> > line 15, in complain
> >     raise ImproperlyConfigured("settings.DATABASES is improperly
> > configured. "
> > django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
> > improperly configured. Please supply the ENGINE value. Check settings
> > documentation for more details.
>
> You're doing nothing wrong! Except you're using the latest Django
> version (1.4) which was released only some days ago... :-)
>
> In Django 1.2 support for multiple databases has been added, so they
> extended the format of the db definition in settings.py. It looks like
> in 1.4 the old format (which we have used so far) is no longer supported
> which most definitely causes the above error to be thrown.
>
> Changing the DATABASE setting in dev_setup/settings.py should do the
> trick. Like here:
> https://docs.djangoproject.com/en/1.4/ref/settings/#databases
>
> I will fix that in our launchpad branch as well, so these changes will
> go into the next alpha (which will probably be released not too far from
> now... :-)
>
> Florian
>
>
>
>
> >
> >
> > Can anyone tell what I am doing wrong?
>
>

Hi Florian,

Thanks for that.

Thata fixed my issue:

[root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python
manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table social_auth_usersocialauth
Creating table social_auth_nonce
Creating table social_auth_association

You just installed Django's auth system, which means you don't have any
superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'root'): admin
E-mail address: odhiambo at gmail.com
Password:
Password (again):
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)


However, I am lost as to why the argument to this procedure was named
"syncdb" and not "createdb", which is what it's doing. Can you explain that
please? Sorry, I am a noob in this.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/0a3ec070/attachment.png>

From odhiambo at gmail.com  Wed Mar 28 18:47:10 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Wed, 28 Mar 2012 19:47:10 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
Message-ID: <CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>

On Wed, Mar 28, 2012 at 19:40, Odhiambo Washington <odhiambo at gmail.com>wrote:

>
>
> On Wed, Mar 28, 2012 at 19:13, Florian Fuchs <f at state-of-mind.de> wrote:
>
>> Hi Odhiambo,
>>
>> Am 28.03.12 17:13, schrieb Odhiambo Washington:
>> > Hey Jeff and all,
>> >
>> > I followed the "five minute guide", but I am hitting a brickwall:
>> >
>> > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>> python
>> > manage.py syncdb
>> > Traceback (most recent call last):
>> >   File "manage.py", line 29, in <module>
>> >     execute_manager(settings)
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
>> > line 459, in execute_manager
>> >     utility.execute()
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/__init__.py",
>> > line 382, in execute
>> >     self.fetch_command(subcommand).run_from_argv(self.argv)
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
>> > line 196, in run_from_argv
>> >     self.execute(*args, **options.__dict__)
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
>> > line 232, in execute
>> >     output = self.handle(*args, **options)
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/base.py",
>> > line 371, in handle
>> >     return self.handle_noargs(**options)
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/management/commands/syncdb.py",
>> > line 57, in handle_noargs
>> >     cursor = connection.cursor()
>> >   File
>> >
>> "/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/db/backends/dummy/base.py",
>> > line 15, in complain
>> >     raise ImproperlyConfigured("settings.DATABASES is improperly
>> > configured. "
>> > django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
>> > improperly configured. Please supply the ENGINE value. Check settings
>> > documentation for more details.
>>
>> You're doing nothing wrong! Except you're using the latest Django
>> version (1.4) which was released only some days ago... :-)
>>
>> In Django 1.2 support for multiple databases has been added, so they
>> extended the format of the db definition in settings.py. It looks like
>> in 1.4 the old format (which we have used so far) is no longer supported
>> which most definitely causes the above error to be thrown.
>>
>> Changing the DATABASE setting in dev_setup/settings.py should do the
>> trick. Like here:
>> https://docs.djangoproject.com/en/1.4/ref/settings/#databases
>>
>> I will fix that in our launchpad branch as well, so these changes will
>> go into the next alpha (which will probably be released not too far from
>> now... :-)
>>
>> Florian
>>
>
One more thing:

In settings.py, I have this:

REST_SERVER = 'http://192.168.40.252:8001'

However, this doesn't seem to be respected when I do runserver:

[root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup# python
manage.py runserver
Validating models...

0 errors found
Django version 1.4, using settings 'dev_setup.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.


[root at jaribu] /usr/home/wash# sockstat -l | grep 800
root     python     77906 3  tcp4   127.0.0.1:8000        *:*
root     python     14108 43 tcp4   127.0.0.1:8001        *:*

Since I am not using the server as a Desktop, I need a way to access it
remotely, not via 127.0.0.1



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/f92df7e7/attachment.png>

From stephen at xemacs.org  Wed Mar 28 19:03:36 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 29 Mar 2012 02:03:36 +0900
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
Message-ID: <CAL_0O1_6S6Bosf=iQJpAsfCu97SffYXuvzqA81FF1NeQ-8hUeA@mail.gmail.com>

On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington <odhiambo at gmail.com> wrote:

> However, I am lost as to why the argument to this procedure was named
> "syncdb" and not "createdb", which is what it's doing. Can you explain that
> please? Sorry, I am a noob in this.

It's called "syncdb" because it synchronizes the actual data store
with the schema, by creating and updating tables and indexes as
necessary.  Creating a database is a special case of syncing where the
database is completely empty.  However, the schema in Django is
dynamic; it will automatically add tables and indexes when the Django
application is changed.

You don't need to know about this unless you plan to dig in and
develop the Django application that provides the administration
interface.

From barry at list.org  Wed Mar 28 19:08:33 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 13:08:33 -0400
Subject: [Mailman-Developers] [Bug 265831] Re: Autoreplies confirm
	subscription invitations
In-Reply-To: <20120328164518.26416.47840.launchpad@wampee.canonical.com>
References: <20080905192619.27052.31438.launchpad@forster.canonical.com>
	<20120328164518.26416.47840.launchpad@wampee.canonical.com>
Message-ID: <20120328130833.71b529cf@resist.wooz.org>

On Mar 28, 2012, at 04:45 PM, Bernard wrote:

>** Changed in: mailman/2.1
>       Status: Fix Committed => Confirmed
>
>** Changed in: mailman/3.0
>       Status: New => Confirmed

Bernard,

While I am glad you've found some enthusiasm for contributing to Mailman,
please stop changing our bug statuses out from underneath us.  You're just
making our work harder this way.

We would welcome you becoming more involved in Mailman, but it's important to
understand our work flow first.  Introduce yourself on the mailman-developers
mailing list, and let us guide you on how to best participate in the project.

Thanks,
-Barry


From odhiambo at gmail.com  Wed Mar 28 20:58:26 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Wed, 28 Mar 2012 21:58:26 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAL_0O1_6S6Bosf=iQJpAsfCu97SffYXuvzqA81FF1NeQ-8hUeA@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAL_0O1_6S6Bosf=iQJpAsfCu97SffYXuvzqA81FF1NeQ-8hUeA@mail.gmail.com>
Message-ID: <CAAdA2WP4UUUuth=f7ihpU9fh0buEpvGKyVycpp4MsLAhBCsDkg@mail.gmail.com>

On Wed, Mar 28, 2012 at 20:03, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington <odhiambo at gmail.com>
> wrote:
>
> > However, I am lost as to why the argument to this procedure was named
> > "syncdb" and not "createdb", which is what it's doing. Can you explain
> that
> > please? Sorry, I am a noob in this.
>
> It's called "syncdb" because it synchronizes the actual data store
> with the schema, by creating and updating tables and indexes as
> necessary.  Creating a database is a special case of syncing where the
> database is completely empty.  However, the schema in Django is
> dynamic; it will automatically add tables and indexes when the Django
> application is changed.
>
> You don't need to know about this unless you plan to dig in and
> develop the Django application that provides the administration
> interface.
>

Thank you for the explanation. I actually accept the argument now:)

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/b0d8fa9d/attachment.png>

From f at state-of-mind.de  Wed Mar 28 21:31:38 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Wed, 28 Mar 2012 21:31:38 +0200
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
Message-ID: <4F73671A.4090700@state-of-mind.de>

Hi Odhiambo,

Am 28.03.12 18:47, schrieb Odhiambo Washington:
> One more thing:
> 
> In settings.py, I have this:
> 
> REST_SERVER = 'http://192.168.40.252:8001'
> 
> However, this doesn't seem to be respected when I do runserver:
> 
> [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
> python manage.py runserver
> Validating models...
> 
> 0 errors found
> Django version 1.4, using settings 'dev_setup.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL-C.
> 
>  
> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> root     python     77906 3  tcp4   127.0.0.1:8000
> <http://127.0.0.1:8000>        *:*
> root     python     14108 43 tcp4   127.0.0.1:8001
> <http://127.0.0.1:8001>        *:*
> 
> Since I am not using the server as a Desktop, I need a way to access it
> remotely, not via 127.0.0.1

The REST_SERVER setting defines the location of Mailman's rest API
(which is frequently accessed by postorius), *not* the address of
postorius itself. The API can only be accessed from localhost, so the
setting has to be 'http://localhost:8001'.

If you'd like to access postorius from a different machine as the one
you're running it on, that's no problem:

Just run the development server like this and you're good to go:

python manage.py runserver 192.168.x.xxx:8000

(Don't do that on a machine that is exposed to the web though, since
Django's dev server is not meant to be run in a production environment.)

Hope that helps!

Florian






> 
> 
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I can't hear you -- I'm using the scrambler.
> Please consider the environment before printing this email.
> 


From f at state-of-mind.de  Wed Mar 28 21:59:57 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Wed, 28 Mar 2012 21:59:57 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
Message-ID: <4F736DBD.9000507@state-of-mind.de>

Hi Ana,

Am 26.03.12 19:03, schrieb Ana Cutillas:
> Hi,
> 
> my name is Ana Cutillas and I am a senior Computer Science student from
> Spain. I am really interested in working on the Mailman project either with
> you directly or with Systers.
> I have been reading the list of ideas to implement and I am very interested
> in the #6 Creating user profiles (
> http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/). I have been
> wanting to work on a project that involved data mining for a while now and
> I think this could be a good opportunity.

This would definitely be a very interesting GSOC project! It might
involve working on a couple of different ends of the mailman family,
like the django web ui (launchpad.net/postorius), the archiver/searcher
(see "hyperkitty" - Toshio Kuratomi probably has more details) and maybe
even the Mailman3 core (see: launchpad.net/mailman).

> In general, I think profiles should have the really straightforward
> information: last time they started a conversation, last time they sent an
> email to the list, when did they sign up, what time of the day are they
> more active, etc. But it should be fairly easy to add cool stuff like, in
> case a list allows the use of more than one language, the language the user
> uses the most and maybe even percentages of usage, and with some
> information retrieval we could get keywords to know what they like to talk
> about the most.

Yes, those would all be very interesting pieces of data.

> I like some of the other ideas too, so I can talk to you about them if you
> want to.

Of course! I think a good place to start would be to install mailman and
postorius and have a look at the code. Also, Toshio could probably tell
you a little bit more about the current work on the archiver. You can
also find us on irc (#mailman on freenode, my handle is florianf,
Toshio's is abadger1999) if you run into problems or have any questions.

Florian


From odhiambo at gmail.com  Wed Mar 28 22:07:21 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Wed, 28 Mar 2012 23:07:21 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F73671A.4090700@state-of-mind.de>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
Message-ID: <CAAdA2WMU_X1StS9k-4Kwj7o0_MzidLQcZnVkq0U2unDbNwZLwg@mail.gmail.com>

On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:

> Hi Odhiambo,
>
> Am 28.03.12 18:47, schrieb Odhiambo Washington:
> > One more thing:
> >
> > In settings.py, I have this:
> >
> > REST_SERVER = 'http://192.168.40.252:8001'
> >
> > However, this doesn't seem to be respected when I do runserver:
> >
> > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
> > python manage.py runserver
> > Validating models...
> >
> > 0 errors found
> > Django version 1.4, using settings 'dev_setup.settings'
> > Development server is running at http://127.0.0.1:8000/
> > Quit the server with CONTROL-C.
> >
> >
> > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> > root     python     77906 3  tcp4   127.0.0.1:8000
> > <http://127.0.0.1:8000>        *:*
> > root     python     14108 43 tcp4   127.0.0.1:8001
> > <http://127.0.0.1:8001>        *:*
> >
> > Since I am not using the server as a Desktop, I need a way to access it
> > remotely, not via 127.0.0.1
>
> The REST_SERVER setting defines the location of Mailman's rest API
> (which is frequently accessed by postorius), *not* the address of
> postorius itself. The API can only be accessed from localhost, so the
> setting has to be 'http://localhost:8001'.
>
> If you'd like to access postorius from a different machine as the one
> you're running it on, that's no problem:
>
> Just run the development server like this and you're good to go:
>
> python manage.py runserver 192.168.x.xxx:8000
>
> (Don't do that on a machine that is exposed to the web though, since
> Django's dev server is not meant to be run in a production environment.)
>
> Hope that helps!
>
> Florian
>
>
Thanks. At least I have a firewall in the name of OpenBSD's PF!

I am yearning for the day MM3 will be production-ready. You guys are doing
a great job!

BTW - Seems MM3 will only be run with Postfix, because the Exim experts
have not embraced it:-(


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/90acb70f/attachment.png>

From janssen at parc.com  Thu Mar 29 03:06:31 2012
From: janssen at parc.com (Bill Janssen)
Date: Wed, 28 Mar 2012 18:06:31 PDT
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
Message-ID: <47418.1332983191@parc.com>

Stephen J. Turnbull <stephen at xemacs.org> wrote:

> On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda <terri at zone12.com> wrote:
> 
> >> Looks like archiver for mm3 is still in development stage. As far as I
> >> understand searcher depends on the srchiver, right? Not completely but it
> >> somewhat depends on archiver. I am not sure if searcher can be implemented
> >> without archiver. If possible I can implement for mm3 also.
> >
> > Searcher and archiver are interdependent *if* we want to share caches and
> > data stores, which we probably do for any installation with larger archives
> > where storing 2 copies vs 4 of each message would make a difference. ?Plus,
> > many archive views may be basically searches "messages in the last month"
> > "messages which are replies to messageid $foo" etc.
> 
> Actually, as far as I can see, the summary/search/index/retrieval
> functions depend only on the API for the message store.  If you
> want, you can split this into the database layer and a presentation
> layer, of course.  However, the database layer is surely going to
> have its own schema optimized for the kinds of retrieval its
> designer considers important.  If the designer emphasizes
> threads, however, she is *not* going to try to store messages in
> thread order or anything like that.  Rather, any reasonable store
> will be message-ID-addressable.

Right.  UpLib has a 'message-store', which the threading code interacts
with to generate threads as data referring to document IDs.  The
message-store API can take both message-IDs or UpLib document IDs and
resolve them.

> The only tricky issue is that we *do* have to worry about
> message-ID collisions of truly different messages and about
> messages without message IDs, especially for converted
> historical archives.  So the API needs to be able to deal
> with these issues, probably by returning a set or sequence
> of messages.

Right.  UpLib takes a message and creates multiple 'documents' (one for
the message, and one for each attachment), each of which have their own
unique 'doc ID', the assigned UpLib ID.  In addition, the email is
assigned a 'mail-guid', which is calculated from some of the header
information and may also include the doc ID.  The metadata of each
attachment refers back to the 'mail-guid' of the message it was part of.

Message-ID, mail-guid, and document ID are all separately indexed for
each document, and any of them can be searched on.

> Oh, and we probably ought to have a more general notion
> of retrievable "object" rather than just messages, as some
> archive/retrieval backends may store some types of MIME
> part separately.  Hopefully these would be presented to
> us as MIME parts with external bodies and content IDs.

Here's how I do it.  In UpLib, a multipart email is analyzed into a
message plus possible attachments.  The parts that are the 'message' are
unified and presented as a document.  The parts that are attachments are
broken out and processed as independent documents, iconified links to
which are then put back into the 'message' document.

See http://uplib.parc.com/misc/noguchi.png for an example of the UpLib
reader, ReadUp, showing a plain-text email with an attached PDF file.
Most of the things that can be links there (like "Reply" or the email
addresses or my name or the URL or the attachment icon and name) are in
fact links.

> And that's all we want to say about the archiver and the
> associated message-retrieval logic, I think.  (In fact, it occurs to
> me that maybe we should say "RFC 3501" and be done with
> it.  I don't mean that we necessarily implement IMAP protocol
> per se, but some subset of its functionality probably is what we
> need from an archiver.)

Yes, there's an IMAP server that runs in UpLib, and can export any
document via IMAP (including archived email).  Though it currently
doesn't scale well; I need to re-write it with Tornado, too.

Bill

From stephen at xemacs.org  Thu Mar 29 03:49:58 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 29 Mar 2012 10:49:58 +0900
Subject: [Mailman-Developers] GSoC
In-Reply-To: <4F736DBD.9000507@state-of-mind.de>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
Message-ID: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>

On Thu, Mar 29, 2012 at 4:59 AM, Florian Fuchs <f at state-of-mind.de> wrote:
> Hi Ana,
>
> Am 26.03.12 19:03, schrieb Ana Cutillas:
>> Hi,
>>
>> my name is Ana Cutillas and I am a senior Computer Science student from
>> Spain. I am really interested in working on the Mailman project either with
>> you directly or with Systers.

Hey, welcome, Ana!  I suspect that the Systers organization has moved
on, since their specific needs were satisfied AFAIK.  But they have
some really good people (both as engineers and as human beings), so
please do get in touch with them (especially the people who worked on
their Mailman projects).  I'm sure they'll be glad to talk with you.

> This would definitely be a very interesting GSOC project! It might
> involve working on a couple of different ends of the mailman family,
> like the django web ui (launchpad.net/postorius), the archiver/searcher
> (see "hyperkitty" - Toshio Kuratomi probably has more details) and maybe
> even the Mailman3 core (see: launchpad.net/mailman).

To be honest, I don't see how it would be related to Postorius, except
perhaps as some sort of plug-in (but we don't have a plug-in
architecture for Postorius, yet).  Adding such features to Postorius
would be bloat, IMO.  I also worry about the performance hit; I think
it should probably maintain its own database, etc for the data-mining
end, and sparingly access the REST client API to update profiles.

> Yes, those would all be very interesting pieces of data.

To stalkers and Tom Clancy's favorite folks, as well as to nicer
people.  Make sure there are opt-outs for users.

> Of course! I think a good place to start would be to install mailman and
> postorius and have a look at the code.

Especially the Mailman client (http://launchpad.net/mailman.client).

> Also, Toshio could probably tell
> you a little bit more about the current work on the archiver.

Note that there is no *the* archiver yet.  Hyperkitty is the demo that
a few people have been working on, including Toshio at the sprints,
but there are others in play (eg, recent posts to this list).  Also,
Hyperkitty is currently based on somewhat limited technology (the
notmuch indexer).  I'm not sure it would be up to the demands of
data-mining.  Of course, if Toshio says it is, listen to him, not me.
:-)

From barry at list.org  Thu Mar 29 01:07:47 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 19:07:47 -0400
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
Message-ID: <20120328190747.3a2c3a66@resist.wooz.org>

On Mar 28, 2012, at 10:29 AM, Stephen J. Turnbull wrote:

>The only tricky issue is that we *do* have to worry about message-ID
>collisions of truly different messages and about messages without message
>IDs, especially for converted historical archives.  So the API needs to be
>able to deal with these issues, probably by returning a set or sequence of
>messages.

Mailman 3 itself requires unique Message-IDs.  IIRC, the Mail Archive guys
found a very very low collision rate over millions of messages, and I think
all such cases were basically spam.  The LMTP runner doesn't yet reject
duplicates, but it should (LP: #967951).

s>I would guess she'll probably store messages in YY-MM/MSGID, or as git does
>in "unpacked" XX/YYYYYYYY... format, where XX are the first two digits of the
>hash ID, and YY... are the remaining ones).  But it could easily be backed by
>an IMAP store or something more specialized; we don't really care as long as
>it's object-ID-addressable.

Don't forget too that the LMTP runner automatically adds the X-Message-ID-Hash
header, which is a Base32 encoding of the SHA1 hash of the Message-ID contents
(without the angle brackets).  This hash could be used as well.

-Barry

From barry at list.org  Thu Mar 29 01:09:47 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 19:09:47 -0400
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <47418.1332983191@parc.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<47418.1332983191@parc.com>
Message-ID: <20120328190947.4badbf77@resist.wooz.org>

On Mar 28, 2012, at 06:06 PM, Bill Janssen wrote:

>Right.  UpLib has a 'message-store', which the threading code interacts
>with to generate threads as data referring to document IDs.  The
>message-store API can take both message-IDs or UpLib document IDs and
>resolve them.

Say Bill, how would you like to work on an implementation of the IArchiver
interface that would work with UpLib?  There should be enough examples in the
mm3 code now to figure out how to do that, but I'd be happy to work with you
or answer any questions you might have.

-Barry

From barry at list.org  Thu Mar 29 01:13:28 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 19:13:28 -0400
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <20120327185103.GZ11151@unaka.lan>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<20120327185103.GZ11151@unaka.lan>
Message-ID: <20120328191328.181fb60a@resist.wooz.org>

On Mar 27, 2012, at 11:51 AM, Toshio Kuratomi wrote:

>The searcher wouldn't be much use without an archiver. There is a sample
>archiver in mailman core -- if enabled, it stores the messages to lists in
>maildirs.  It does not have a frontend for retrieving or otherwise
>displaying the archives.

Yet. :)

Probably a simplistic approach would be to extend the REST API to expose the
IMessageStore as a top-level resource.  At the simplest, it could provide a
GET API which would accept Message-ID or X-Message-ID-Hash values and return
the contents of the message, or a 404 if it doesn't exist in the store.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/f1ffe9da/attachment.pgp>

From barry at list.org  Thu Mar 29 01:17:24 2012
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Mar 2012 19:17:24 -0400
Subject: [Mailman-Developers] GSoC 2012
In-Reply-To: <CAKpG3NjD=N6BLMwMfbWvsdC+CARYvowaZqKfxbgnk3ft2M_b_A@mail.gmail.com>
References: <CAKpG3NjD=N6BLMwMfbWvsdC+CARYvowaZqKfxbgnk3ft2M_b_A@mail.gmail.com>
Message-ID: <20120328191724.4d865102@resist.wooz.org>

On Mar 24, 2012, at 03:19 AM, vikash agrawal wrote:

>I am Vikash and very much interested in contributing to mailman and being a
>GSoC student this year. So far, I have successfully installed mailman in my
>system.

Welcome!

>I do have skills in Python 2.7 but as I am very new to mailman thus I am
>looking for something small to hack and doable in this summer.  Also, the
>idea page doesnot mention the skills required for the project so its somewhat
>difficult for me to choose one. As a result I would like you to guide me over
>the same .  I am willing to learn a lot this summer :-)

Fantastic!  This is the right place to ask questions.  Also many of us hang
out on IRC using the freenode channel #mailman.

Note that I've started to tag bugs in the tracker with 'easy' if I think they
are (but I could be wrong :).  So you could search bugs.launchpad.net/mailman
for the 'easy' and 'mailman3' tags to find things to get started with.

Cheers,
-Barry


From davidj at gmail.com  Thu Mar 29 06:00:13 2012
From: davidj at gmail.com (David Jeske)
Date: Wed, 28 Mar 2012 21:00:13 -0700
Subject: [Mailman-Developers] mailman / archive-ui / licensing questions
Message-ID: <CA+CP9O48F8FXr5ya4_z=g3jPujs=c=_30=9O0Np0iCpFjibt0w@mail.gmail.com>

Thanks for the super-detailed replies... I'm separating these discussions,
so here I have some questions about licensing and bundling..

> So in some sense, CSLA needn't become *the* Mailman archiver, but it should
> definitely be *a* Mailman archiver.  Then you can make all the engineering
> and
> design decisions you prefer, but with the confidence that it will Just Work
> with Mailman 3.


Sure but this isn't why I'm here. CSLA is already *a* mailman archiver..I
think we first released it in 2004. A few of us ex-egroups folks hacked it
out because we used it for private projects. We open-sourced it so we could
use it across organizational boundaries and because we were happy to give
it away to anyone who wanted it. We're just all primarily focused on
startup and commercial endeavors, so we havn't done much to package and
popularize it.

Right now I'm in between entrepreneural endeavors and spending some time
'giving back' and coding/donating-to/helping several open-source projects.
As I engage with these projects, all of them are using Mailman, which is
fantastic. However, nearly all of them are also using pipermail, which is
not so great. They are using it because it's the default, so it was easy.

I started to talk to one of them about installing CSLA (or MHonArc, or
anything really), and realized I should see if you folks are interested in
a great bundled archiver, to fix the problem at the source. I'm not
particularly interested in promoting or maintaining an open-source project
around this, so if you folks don't want a shiny new (S-BSD licensed)
archiver to bundle, I'll probably just fix a few things, bump the CSLA
archiver to 0.3 and move on.

---

I admit that even with a pretty good knowledge of these many licenses, I'm
not familiar with the intracacies of FSF copyright assignment and non-GPL
free licenses.

The ClearsilverArchiver code (written by me and two others) is released
under the "Simplified BSD" license and "totally free". It's important to me
that any code I release be similarly free-and-unrestricted
(i.e. BSD/Python/Artistic/PublicDomain), not free under certain conditions
(i.e. GPL/LGPL). It's not possible to assert GPL restrictions on
totally-free code, because it's already totally free.

FSF says S-BSD is GPL-Compatible, which I believe means they are saying
they have no problem with GPL code depending on and being combined with
(i.e. linked with) S-BSD code, because the S-BSD code is fully open-source
and does not put restrictions on the use of the GPL code.

It's also my understanding that the primary reason for FSF copyright
assignment is to provide a coherent entity to enforce the terms of the GPL
by challenging violators who don't redistribute source.... something which
is not necessary for S-BSD. (Though I suppose they could enforce that folks
include the S-BSD copyright notices.)

So I guess this all drives to the following question:

Is Mailman-team is interested in having a better built-in archiver that is
included in the distribution, but licensed under the less-restrictive S-BSD
terms?

Sorry for the length. This license stuff can be complicated.


-- 

On a weirdly unrelated coincidence, thanks for smtpd.py. I just hacked it
into smtp-to-maildir for a "private hosted webmail" installation. We were
migrating code/data to some new machines and smtpd.py seemed simpler than
fighting with qmail-installation or configuring postfix to "accept
everything" (something it doesn't seem designed to do).

> But that absolutely shouldn't stop any other third party archiver from
being

> Mailman 3 compatible.
>
> As I said, like the Python standard library, it's both a blessing and a
> curse. :)
>
> >As for the features it doesn't have from your list: Editing would be easy
> >to add because it's sqlite (deciding on the auth system is probably more
of
> >an issue than the editing). Anti-Crawl code is really an issue of
> >configuration for cheap in-memory state-management. NNTP is well. that
> >would be a big job that I doubt will be bitten off by something as
"small"
> >as a list archiver.
>
> Why can't we kill off Gmane while we're killing off Gmail, and *Groups?
:).
>
> >What is the REST UI used by? CSLA supports RSS. When it comes to a more
> >involved REST UI, what software would be hitting it? I don't think I'll
> >understand your other API/REST points until I see an answer to this.
>
> I'm a list owner and someone requests that a post containing private
> information be taken down.
>
> As a drive-by archive user, I want to request that a message get sent to
me so
> that I can reply to it in my mail reader as if I had received the
original.
>
> I run a question/answer forum that gateways a list, and I want to +1
really
> helpful messages, or give some extra kudos to really helpful users.
>
> -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/davidj%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9

From jeff at jab.org  Thu Mar 29 08:10:58 2012
From: jeff at jab.org (Jeff Breidenbach)
Date: Wed, 28 Mar 2012 23:10:58 -0700
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1
 andPostorius 1.0 alpha 1
In-Reply-To: <20120328115324.6ddfccd0@rivendell>
References: <CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<PC195201203251548530765aee868f2@MSAPIRO>
	<CAHjiUbqvkWKt80_pYy5D6DvTAS28O8W+n6DPqyUf11yEC47dEA@mail.gmail.com>
	<20120328115324.6ddfccd0@rivendell>
Message-ID: <CAHjiUbpk4Jqrn7EdPpYat022h3SW8UZOW2whc6+4Ma3o2iL=Sw@mail.gmail.com>

> Ah, sorry, yes the two booleans above should be exposed in the REST API.
> https://bugs.launchpad.net/mailman/+bug/967238

Thanks, I've added some comments and questions to bug entry.

Jeff

From davidj at gmail.com  Thu Mar 29 08:35:35 2012
From: davidj at gmail.com (David Jeske)
Date: Wed, 28 Mar 2012 23:35:35 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327234649.74f034ea@resist.wooz.org>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
	<CA+CP9O7Jvg-1EvGUuQ5jJHXWD+AcuEM0rrGxVDu7XCZrJpnNLA@mail.gmail.com>
	<20120327234649.74f034ea@resist.wooz.org>
Message-ID: <CA+CP9O4qHmrOdw+TEce2v14oo8qUxzRkWuvwww7fJfg4hS41Sg@mail.gmail.com>

On Mar 27, 2012 8:47 PM, "Barry Warsaw" <barry at list.org> wrote:
> .... but that we're pretty far away from being
> able to bless an archiver right now.

I just want to be clear, that I'm obviously not asking for anyone to bless
a specific archiver and roll it into the distribution.

I'm trying to get some idea what requirements an  archiver would need to
meet for you folks to jump for joy and roll it into the MM2 and MM3
distros  -- because my goal is to (with respect and fondness) exterminate
pipermail for the betterment of all. Along these lines, I've been thinking
that in addition to a dynamic rendering system (like CSLA), it might be
worth it to include a static-html generation model a bit more like
pipermail ... as some sites may prefer it and it's easy to do.

If there is a compatible set of goals I'll gladly offer / retool rewrite my
stuff to make folks happy.

.. if requirement #1 is GPL, then sadly I'll have to rethink my
extermination plan, because GPL is not a jeske-compatible-license. :)

> Why can't we kill off Gmane while we're killing off
> Gmail, and *Groups? :).

Is that the primary niche for gmane? Folks who want to read mailing lists
via NNTP clients? What is the motivation for NNTP support? I don't think it
would be too bad to support NNTP clients, it's NNTP sync that is more
involved. I just don't know why anyone would want to use an NNTP client
anymore.

As for killing off things, don't get me started. I'm very unhappy with the
new over-ajax Groups UI, and the fact that they seem to have broke the
faceted directory browser. The old html-with-javascript-tweaks is so much
faster and lighter on all browsers (especially mobile).

> >What is the REST UI used by? CSLA supports RSS. When it comes to a more
> >involved REST UI, what software would be hitting it? I don't think I'll
> >understand your other API/REST points until I see an answer to this.
>
> I'm a list owner and someone requests that a post containing private
> information be taken down.

I would expect the user/list-owner go to the
new-builtin-super-cool-mm-archive-web-ui to request/approve-takedown..
which would have CGIs and UI to directly modify it's data. The only REST
API I see is for validating the user-cookie, checking his auth-permissinos,
etc.

Is that what you are thinking, or am I missing some part of your thinking?

From terri at zone12.com  Thu Mar 29 08:51:45 2012
From: terri at zone12.com (Terri Oda)
Date: Thu, 29 Mar 2012 00:51:45 -0600
Subject: [Mailman-Developers] GSoC Mailman and Systers (was Re:  GSoC)
In-Reply-To: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
Message-ID: <4F740681.3090307@zone12.com>



On 12-03-28 7:49 PM, Stephen J. Turnbull wrote:
> Hey, welcome, Ana! I suspect that the Systers organization has moved 
> on, since their specific needs were satisfied AFAIK. But they have 
> some really good people (both as engineers and as human beings), so 
> please do get in touch with them (especially the people who worked on 
> their Mailman projects). I'm sure they'll be glad to talk with you. 
*laugh* Stephen, maybe I should have mentioned that I'm *also* a GSoC 
mentor (and one of several org admins) for Systers, and we are indeed 
doing some Mailman related projects this year.

For the most part, I've kept the suggested projects separate on the 
respective GSoC 2012 projects page.  Systers is the obvious candidate 
for some Mailman 3 related projects, specifically dynamic sublists 
(which was invented for Systers and I hope to have replace topics in 
Mailman 3) and some usability work I'd like done on the admin interface 
(Systers has an experienced usability expert on our mentoring team who's 
agreed to help if we can find the right student).  And of course, 
Systers still has wishlists for their current custom install which is 
based on Mailman 2.1.10 and other organizational projects.

There's a bit of a grey area where students could put in a submission 
under either Systers or Mailman, though.  Archives work, for example, 
could probably go with either.  I'm pretty much waiting to see and 
hoping we've got enough mentors to go around.

  Terri

From odhiambo at gmail.com  Thu Mar 29 08:58:11 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Thu, 29 Mar 2012 09:58:11 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F73671A.4090700@state-of-mind.de>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
Message-ID: <CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>

On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:

> Hi Odhiambo,
>
> Am 28.03.12 18:47, schrieb Odhiambo Washington:
> > One more thing:
> >
> > In settings.py, I have this:
> >
> > REST_SERVER = 'http://192.168.40.252:8001'
> >
> > However, this doesn't seem to be respected when I do runserver:
> >
> > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
> > python manage.py runserver
> > Validating models...
> >
> > 0 errors found
> > Django version 1.4, using settings 'dev_setup.settings'
> > Development server is running at http://127.0.0.1:8000/
> > Quit the server with CONTROL-C.
> >
> >
> > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> > root     python     77906 3  tcp4   127.0.0.1:8000
> > <http://127.0.0.1:8000>        *:*
> > root     python     14108 43 tcp4   127.0.0.1:8001
> > <http://127.0.0.1:8001>        *:*
> >
> > Since I am not using the server as a Desktop, I need a way to access it
> > remotely, not via 127.0.0.1
>
> The REST_SERVER setting defines the location of Mailman's rest API
> (which is frequently accessed by postorius), *not* the address of
> postorius itself. The API can only be accessed from localhost, so the
> setting has to be 'http://localhost:8001'.
>
> If you'd like to access postorius from a different machine as the one
> you're running it on, that's no problem:
>
> Just run the development server like this and you're good to go:
>
> python manage.py runserver 192.168.x.xxx:8000
>
> (Don't do that on a machine that is exposed to the web though, since
> Django's dev server is not meant to be run in a production environment.)
>
> Hope that helps!
>
> Florian
>
>

My current quest is to see what MM3 web UI looks like, but it appears I am
still way behind.
I get these errors in the backend when I run posturious and try to access
it:

http://bit.ly/H2rDuW


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/a57eefba/attachment.png>

From davidj at gmail.com  Thu Mar 29 09:04:45 2012
From: davidj at gmail.com (David Jeske)
Date: Thu, 29 Mar 2012 00:04:45 -0700
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327182908.573b8c96@resist.wooz.org>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327182908.573b8c96@resist.wooz.org>
Message-ID: <CA+CP9O4hHRjVboe6wBRg+juRAJWA1Utiyu0Kxz1RVAL+jbRcdw@mail.gmail.com>

> - Stable URLs, RFC 5064 + X-Message-ID-Hash.
> See the above links.  If you can implement the
> `IArchiver.permalink()` method and ensure that even if
>  completely wiped and regenerated from the
> underlying raw messages, your URLs
>  will remain stable, I think you will have won. :)

This is really trivial to implement.

HOWEVER, it also has two notable problems.

First, if the sender-selected-messageID is trusted to make a unique-id and
permalink, then you are trusting senders, which IMO is a bad idea. What
happens when senders intentionally duplicate a message-id? It's pretty hard
to do anything smart when the listprocessor doesn't track messageids.

Second, when message-id uniqueness breaks, it's often not an isolated
instance, but a pattern of software doing bad things.

I prefer generating a trustably unique message IDs, even if those are only
used internally. I've used partial-content hashes in the past, but they
have their tradeoffs. They are hard to abuse, since matching a content hash
tends to mean supplying the same content, which kinda prevents abuse.
However, if the content is being changed at all (intentionally or not),
they breakdown.

---

I like your ideas about plug-in text-match-formatters. We have something
like that in the willowmail system, and it's pretty useful. (auto-linking
fedex tracking numbers in email is one example)

> - Merging of forums, archives, newsgroups, and IMAP.

You like to bite off the big ones eh? NNTP, then IMAP.

Does anyone even use fat-mail-clients anymore? Even the IMAP clients I've
used in recent years have been web-based..... which is kinda already
unified with web-based archives since they are both in the browser. :)

Seriously though, what is the goal here?

I suppose I've had one thought over the years, which is that sometimes it
seems weird that I have all these mailing lists delivering into my mail
client. In theory my mail client could be 'faking' the whole thing with
NNTP to a known archive location.

However, that only works when online. If you have to do delivery to my
client, who cares if it's SMTP/NNTP/IMAP? I say pick the simplest one
(SMTP), which works with all mail clients, no changes, and allows you to
keep your messages when the archive goes down.

As for mail-client integration features... I like mail-client push-button
unsubscribe. I like the idea of making it trivial for mail clients to
recognize mailing lists posts and auto-configure filter-to-folder for them.
Neither of these require NNTP/IMAP in the archive though.

From mdoshayan at gmail.com  Thu Mar 29 09:33:28 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Thu, 29 Mar 2012 13:03:28 +0530
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
Message-ID: <CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>

On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:

> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:
>
> > Hi Odhiambo,
> >
> > Am 28.03.12 18:47, schrieb Odhiambo Washington:
> > > One more thing:
> > >
> > > In settings.py, I have this:
> > >
> > > REST_SERVER = 'http://192.168.40.252:8001'
> > >
> > > However, this doesn't seem to be respected when I do runserver:
> > >
> > > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
> > > python manage.py runserver
> > > Validating models...
> > >
> > > 0 errors found
> > > Django version 1.4, using settings 'dev_setup.settings'
> > > Development server is running at http://127.0.0.1:8000/
> > > Quit the server with CONTROL-C.
> > >
> > >
> > > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> > > root     python     77906 3  tcp4   127.0.0.1:8000
> > > <http://127.0.0.1:8000>        *:*
> > > root     python     14108 43 tcp4   127.0.0.1:8001
> > > <http://127.0.0.1:8001>        *:*
> > >
> > > Since I am not using the server as a Desktop, I need a way to access it
> > > remotely, not via 127.0.0.1
> >
> > The REST_SERVER setting defines the location of Mailman's rest API
> > (which is frequently accessed by postorius), *not* the address of
> > postorius itself. The API can only be accessed from localhost, so the
> > setting has to be 'http://localhost:8001'.
> >
> > If you'd like to access postorius from a different machine as the one
> > you're running it on, that's no problem:
> >
> > Just run the development server like this and you're good to go:
> >
> > python manage.py runserver 192.168.x.xxx:8000
> >
> > (Don't do that on a machine that is exposed to the web though, since
> > Django's dev server is not meant to be run in a production environment.)
> >
> > Hope that helps!
> >
> > Florian
> >
> >
>
> My current quest is to see what MM3 web UI looks like, but it appears I am
> still way behind.
> I get these errors in the backend when I run posturious and try to access
> it:
>
> http://bit.ly/H2rDuW
>
Looks like you didn't start mailman server. Go through this[1] page to
setup mailman3.

[1]
http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running

>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I can't hear you -- I'm using the scrambler.
> Please consider the environment before printing this email.
>
> _______________________________________________
> 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/mdoshayan%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From odhiambo at gmail.com  Thu Mar 29 09:37:52 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Thu, 29 Mar 2012 10:37:52 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
Message-ID: <CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>

On Thu, Mar 29, 2012 at 10:33, Shayan Md <mdoshayan at gmail.com> wrote:

>
>
> On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:
>
>> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:
>>
>> > Hi Odhiambo,
>> >
>> > Am 28.03.12 18:47, schrieb Odhiambo Washington:
>> > > One more thing:
>> > >
>> > > In settings.py, I have this:
>> > >
>> > > REST_SERVER = 'http://192.168.40.252:8001'
>> > >
>> > > However, this doesn't seem to be respected when I do runserver:
>> > >
>> > > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>> > > python manage.py runserver
>> > > Validating models...
>> > >
>> > > 0 errors found
>> > > Django version 1.4, using settings 'dev_setup.settings'
>> > > Development server is running at http://127.0.0.1:8000/
>> > > Quit the server with CONTROL-C.
>> > >
>> > >
>> > > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>> > > root     python     77906 3  tcp4   127.0.0.1:8000
>> > > <http://127.0.0.1:8000>        *:*
>> > > root     python     14108 43 tcp4   127.0.0.1:8001
>> > > <http://127.0.0.1:8001>        *:*
>> > >
>> > > Since I am not using the server as a Desktop, I need a way to access
>> it
>> > > remotely, not via 127.0.0.1
>> >
>> > The REST_SERVER setting defines the location of Mailman's rest API
>> > (which is frequently accessed by postorius), *not* the address of
>> > postorius itself. The API can only be accessed from localhost, so the
>> > setting has to be 'http://localhost:8001'.
>> >
>> > If you'd like to access postorius from a different machine as the one
>> > you're running it on, that's no problem:
>> >
>> > Just run the development server like this and you're good to go:
>> >
>> > python manage.py runserver 192.168.x.xxx:8000
>> >
>> > (Don't do that on a machine that is exposed to the web though, since
>> > Django's dev server is not meant to be run in a production environment.)
>> >
>> > Hope that helps!
>> >
>> > Florian
>> >
>> >
>>
>> My current quest is to see what MM3 web UI looks like, but it appears I am
>> still way behind.
>> I get these errors in the backend when I run posturious and try to access
>> it:
>>
>> http://bit.ly/H2rDuW
>>
> Looks like you didn't start mailman server. Go through this[1] page to
> setup mailman3.
>
> [1]
> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>
>
Maybe and maybe not, as I was following this very guide!

[wash at jaribu ~/public_html]$ ps ax | grep mailman
70295  ??  Is      0:00.40 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/master
70298  ??  S       0:01.52 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=news:0:1
70299  ??  S       0:01.57 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=in:0:1
70300  ??  S       0:01.46 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=digest:0:1
70301  ??  S       0:01.49 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=pipeline:0:1
70302  ??  S       0:01.45 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=archive:0:1
70303  ??  S       0:01.46 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=out:0:1
70304  ??  I       0:00.41 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=retry:0:1
70305  ??  S       0:01.17 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=rest:0:1
70306  ??  S       0:01.46 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=bounces:0:1
70307  ??  S       0:00.43 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=lmtp:0:1
70308  ??  S       0:01.45 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=command:0:1
70309  ??  S       0:01.50 /usr/local/bin/python
/usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
--runner=virgin:0:1
78850   1  S+      0:00.01 grep mailman

Is there something amiss?

[root at jaribu] /usr/home/wash# sockstat -l | grep 800
root     python     70442 3  tcp4   192.168.40.252:8000   *:*
root     python     70305 43 tcp4   127.0.0.1:8001        *:*


I suppose the 8001 is mailman and 8000 is posturious.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/bdc6decd/attachment.png>

From mdoshayan at gmail.com  Thu Mar 29 09:45:15 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Thu, 29 Mar 2012 13:15:15 +0530
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
Message-ID: <CAKfaKcN0_ifzoy+c2o6=EqY2sDni1QuzaWuoBzdw-S3OEx66rg@mail.gmail.com>

On Thu, Mar 29, 2012 at 1:07 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:

>
>
> On Thu, Mar 29, 2012 at 10:33, Shayan Md <mdoshayan at gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <odhiambo at gmail.com
>> > wrote:
>>
>>> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:
>>>
>>> > Hi Odhiambo,
>>> >
>>> > Am 28.03.12 18:47, schrieb Odhiambo Washington:
>>> > > One more thing:
>>> > >
>>> > > In settings.py, I have this:
>>> > >
>>> > > REST_SERVER = 'http://192.168.40.252:8001'
>>> > >
>>> > > However, this doesn't seem to be respected when I do runserver:
>>> > >
>>> > > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>>> > > python manage.py runserver
>>> > > Validating models...
>>> > >
>>> > > 0 errors found
>>> > > Django version 1.4, using settings 'dev_setup.settings'
>>> > > Development server is running at http://127.0.0.1:8000/
>>> > > Quit the server with CONTROL-C.
>>> > >
>>> > >
>>> > > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>>> > > root     python     77906 3  tcp4   127.0.0.1:8000
>>> > > <http://127.0.0.1:8000>        *:*
>>> > > root     python     14108 43 tcp4   127.0.0.1:8001
>>> > > <http://127.0.0.1:8001>        *:*
>>> > >
>>> > > Since I am not using the server as a Desktop, I need a way to access
>>> it
>>> > > remotely, not via 127.0.0.1
>>> >
>>> > The REST_SERVER setting defines the location of Mailman's rest API
>>> > (which is frequently accessed by postorius), *not* the address of
>>> > postorius itself. The API can only be accessed from localhost, so the
>>> > setting has to be 'http://localhost:8001'.
>>> >
>>> > If you'd like to access postorius from a different machine as the one
>>> > you're running it on, that's no problem:
>>> >
>>> > Just run the development server like this and you're good to go:
>>> >
>>> > python manage.py runserver 192.168.x.xxx:8000
>>> >
>>> > (Don't do that on a machine that is exposed to the web though, since
>>> > Django's dev server is not meant to be run in a production
>>> environment.)
>>> >
>>> > Hope that helps!
>>> >
>>> > Florian
>>> >
>>> >
>>>
>>> My current quest is to see what MM3 web UI looks like, but it appears I
>>> am
>>> still way behind.
>>> I get these errors in the backend when I run posturious and try to access
>>> it:
>>>
>>> http://bit.ly/H2rDuW
>>>
>> Looks like you didn't start mailman server. Go through this[1] page to
>> setup mailman3.
>>
>> [1]
>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>
>>
> Maybe and maybe not, as I was following this very guide!
>
> [wash at jaribu ~/public_html]$ ps ax | grep mailman
> 70295  ??  Is      0:00.40 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/master
> 70298  ??  S       0:01.52 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=news:0:1
> 70299  ??  S       0:01.57 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=in:0:1
> 70300  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=digest:0:1
> 70301  ??  S       0:01.49 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=pipeline:0:1
> 70302  ??  S       0:01.45 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=archive:0:1
> 70303  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=out:0:1
> 70304  ??  I       0:00.41 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=retry:0:1
> 70305  ??  S       0:01.17 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=rest:0:1
> 70306  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=bounces:0:1
> 70307  ??  S       0:00.43 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=lmtp:0:1
> 70308  ??  S       0:01.45 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=command:0:1
> 70309  ??  S       0:01.50 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=virgin:0:1
> 78850   1  S+      0:00.01 grep mailman
>
> Is there something amiss?
>
>
> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> root     python     70442 3  tcp4   192.168.40.252:8000   *:*
> root     python     70305 43 tcp4   127.0.0.1:8001        *:*
>
>
> I suppose the 8001 is mailman and 8000 is posturious.
>
> Err.. I was wrong. It must be something else, which I don't know.

>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I can't hear you -- I'm using the scrambler.
> Please consider the environment before printing this email.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/d3de95da/attachment-0001.png>

From terri at zone12.com  Thu Mar 29 09:52:00 2012
From: terri at zone12.com (Terri Oda)
Date: Thu, 29 Mar 2012 01:52:00 -0600
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
Message-ID: <4F7414A0.7000702@zone12.com>

On 12-03-29 12:58 AM, Odhiambo Washington wrote:
> My current quest is to see what MM3 web UI looks like, but it appears 
> I am still way behind. I get these errors in the backend when I run 
> posturious and try to access it: http://bit.ly/H2rDuW
>
I'm very fuzzy on this, but I think I got a similar problem during one 
of my many updates and it was due to updating code without restarting 
Mailman and re-running syncdb.  But I'm pretty sure you don't have an 
out-of-sync error between mailman.client and postorius like I had then.

You might also want to try Django 1.3.1 just in case it's a 1.4 issue.  
Florian might know more; I haven't upgraded django yet myself.

  Terri


From terri at zone12.com  Thu Mar 29 09:57:03 2012
From: terri at zone12.com (Terri Oda)
Date: Thu, 29 Mar 2012 01:57:03 -0600
Subject: [Mailman-Developers] Additional Mailman GSoC mentors
Message-ID: <4F7415CF.20304@zone12.com>

It's looking like we're going to have more student applicants than in 
previous years, so I think it'd be great if we could get a few more 
mentors to match.

If you're a semi-active mailman developer (i.e. I'm going to recognize 
your name from your mailman-developers postings) and you think you might 
interested in mentoring for GSoC this summer or just want to know what's 
involved, please get in touch with me!

  Terri


From mdoshayan at gmail.com  Thu Mar 29 10:12:08 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Thu, 29 Mar 2012 13:42:08 +0530
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
Message-ID: <CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>

On Thu, Mar 29, 2012 at 1:07 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:

>
>
> On Thu, Mar 29, 2012 at 10:33, Shayan Md <mdoshayan at gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <odhiambo at gmail.com
>> > wrote:
>>
>>> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de> wrote:
>>>
>>> > Hi Odhiambo,
>>> >
>>> > Am 28.03.12 18:47, schrieb Odhiambo Washington:
>>> > > One more thing:
>>> > >
>>> > > In settings.py, I have this:
>>> > >
>>> > > REST_SERVER = 'http://192.168.40.252:8001'
>>> > >
>>> > > However, this doesn't seem to be respected when I do runserver:
>>> > >
>>> > > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>>> > > python manage.py runserver
>>> > > Validating models...
>>> > >
>>> > > 0 errors found
>>> > > Django version 1.4, using settings 'dev_setup.settings'
>>> > > Development server is running at http://127.0.0.1:8000/
>>> > > Quit the server with CONTROL-C.
>>> > >
>>> > >
>>> > > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>>> > > root     python     77906 3  tcp4   127.0.0.1:8000
>>> > > <http://127.0.0.1:8000>        *:*
>>> > > root     python     14108 43 tcp4   127.0.0.1:8001
>>> > > <http://127.0.0.1:8001>        *:*
>>> > >
>>> > > Since I am not using the server as a Desktop, I need a way to access
>>> it
>>> > > remotely, not via 127.0.0.1
>>> >
>>> > The REST_SERVER setting defines the location of Mailman's rest API
>>> > (which is frequently accessed by postorius), *not* the address of
>>> > postorius itself. The API can only be accessed from localhost, so the
>>> > setting has to be 'http://localhost:8001'.
>>> >
>>> > If you'd like to access postorius from a different machine as the one
>>> > you're running it on, that's no problem:
>>> >
>>> > Just run the development server like this and you're good to go:
>>> >
>>> > python manage.py runserver 192.168.x.xxx:8000
>>> >
>>> > (Don't do that on a machine that is exposed to the web though, since
>>> > Django's dev server is not meant to be run in a production
>>> environment.)
>>> >
>>> > Hope that helps!
>>> >
>>> > Florian
>>> >
>>> >
>>>
>>> My current quest is to see what MM3 web UI looks like, but it appears I
>>> am
>>> still way behind.
>>> I get these errors in the backend when I run posturious and try to access
>>> it:
>>>
>>> http://bit.ly/H2rDuW
>>>
>> Looks like you didn't start mailman server. Go through this[1] page to
>> setup mailman3.
>>
>> [1]
>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>
>>
> Maybe and maybe not, as I was following this very guide!
>
> [wash at jaribu ~/public_html]$ ps ax | grep mailman
> 70295  ??  Is      0:00.40 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/master
> 70298  ??  S       0:01.52 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=news:0:1
> 70299  ??  S       0:01.57 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=in:0:1
> 70300  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=digest:0:1
> 70301  ??  S       0:01.49 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=pipeline:0:1
> 70302  ??  S       0:01.45 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=archive:0:1
> 70303  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=out:0:1
> 70304  ??  I       0:00.41 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=retry:0:1
> 70305  ??  S       0:01.17 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=rest:0:1
> 70306  ??  S       0:01.46 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=bounces:0:1
> 70307  ??  S       0:00.43 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=lmtp:0:1
> 70308  ??  S       0:01.45 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=command:0:1
> 70309  ??  S       0:01.50 /usr/local/bin/python
> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
> --runner=virgin:0:1
> 78850   1  S+      0:00.01 grep mailman
>
> Is there something amiss?
>
>
> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
> root     python     70442 3  tcp4   192.168.40.252:8000   *:*
> root     python     70305 43 tcp4   127.0.0.1:8001        *:*
>
>
> I suppose the 8001 is mailman and 8000 is posturious.

Downgrading to django 1.3 might do the trick. Same error here
https://answers.launchpad.net/graphite/+question/191549

>
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I can't hear you -- I'm using the scrambler.
> Please consider the environment before printing this email.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/8c0a4d99/attachment.png>

From odhiambo at gmail.com  Thu Mar 29 10:51:25 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Thu, 29 Mar 2012 11:51:25 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
	<CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
Message-ID: <CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>

On Thu, Mar 29, 2012 at 11:12, Shayan Md <mdoshayan at gmail.com> wrote:

>
>
> On Thu, Mar 29, 2012 at 1:07 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:
>
>>
>>
>> On Thu, Mar 29, 2012 at 10:33, Shayan Md <mdoshayan at gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <
>>> odhiambo at gmail.com> wrote:
>>>
>>>> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de>
>>>> wrote:
>>>>
>>>> > Hi Odhiambo,
>>>> >
>>>> > Am 28.03.12 18:47, schrieb Odhiambo Washington:
>>>> > > One more thing:
>>>> > >
>>>> > > In settings.py, I have this:
>>>> > >
>>>> > > REST_SERVER = 'http://192.168.40.252:8001'
>>>> > >
>>>> > > However, this doesn't seem to be respected when I do runserver:
>>>> > >
>>>> > > [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>>>> > > python manage.py runserver
>>>> > > Validating models...
>>>> > >
>>>> > > 0 errors found
>>>> > > Django version 1.4, using settings 'dev_setup.settings'
>>>> > > Development server is running at http://127.0.0.1:8000/
>>>> > > Quit the server with CONTROL-C.
>>>> > >
>>>> > >
>>>> > > [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>>>> > > root     python     77906 3  tcp4   127.0.0.1:8000
>>>> > > <http://127.0.0.1:8000>        *:*
>>>> > > root     python     14108 43 tcp4   127.0.0.1:8001
>>>> > > <http://127.0.0.1:8001>        *:*
>>>> > >
>>>> > > Since I am not using the server as a Desktop, I need a way to
>>>> access it
>>>> > > remotely, not via 127.0.0.1
>>>> >
>>>> > The REST_SERVER setting defines the location of Mailman's rest API
>>>> > (which is frequently accessed by postorius), *not* the address of
>>>> > postorius itself. The API can only be accessed from localhost, so the
>>>> > setting has to be 'http://localhost:8001'.
>>>> >
>>>> > If you'd like to access postorius from a different machine as the one
>>>> > you're running it on, that's no problem:
>>>> >
>>>> > Just run the development server like this and you're good to go:
>>>> >
>>>> > python manage.py runserver 192.168.x.xxx:8000
>>>> >
>>>> > (Don't do that on a machine that is exposed to the web though, since
>>>> > Django's dev server is not meant to be run in a production
>>>> environment.)
>>>> >
>>>> > Hope that helps!
>>>> >
>>>> > Florian
>>>> >
>>>> >
>>>>
>>>> My current quest is to see what MM3 web UI looks like, but it appears I
>>>> am
>>>> still way behind.
>>>> I get these errors in the backend when I run posturious and try to
>>>> access
>>>> it:
>>>>
>>>> http://bit.ly/H2rDuW
>>>>
>>> Looks like you didn't start mailman server. Go through this[1] page to
>>> setup mailman3.
>>>
>>> [1]
>>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>>
>>>
>> Maybe and maybe not, as I was following this very guide!
>>
>> [wash at jaribu ~/public_html]$ ps ax | grep mailman
>> 70295  ??  Is      0:00.40 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/master
>> 70298  ??  S       0:01.52 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=news:0:1
>> 70299  ??  S       0:01.57 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=in:0:1
>> 70300  ??  S       0:01.46 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=digest:0:1
>> 70301  ??  S       0:01.49 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=pipeline:0:1
>> 70302  ??  S       0:01.45 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=archive:0:1
>> 70303  ??  S       0:01.46 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=out:0:1
>> 70304  ??  I       0:00.41 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=retry:0:1
>> 70305  ??  S       0:01.17 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=rest:0:1
>> 70306  ??  S       0:01.46 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=bounces:0:1
>> 70307  ??  S       0:00.43 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=lmtp:0:1
>> 70308  ??  S       0:01.45 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=command:0:1
>> 70309  ??  S       0:01.50 /usr/local/bin/python
>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>> --runner=virgin:0:1
>> 78850   1  S+      0:00.01 grep mailman
>>
>> Is there something amiss?
>>
>>
>> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>> root     python     70442 3  tcp4   192.168.40.252:8000   *:*
>> root     python     70305 43 tcp4   127.0.0.1:8001        *:*
>>
>>
>> I suppose the 8001 is mailman and 8000 is posturious.
>
> Downgrading to django 1.3 might do the trick. Same error here
> https://answers.launchpad.net/graphite/+question/191549
>
>>
>>
>>
Okay. I have to figure out why the consensus is that I am running django
1.4 while I actually installed 1.3.1:

[root at jaribu] /usr/ports/www/py-django# ls -al /var/db/pkg/ | grep django
drwxr-xr-x     2 root  wheel       512 Mar 26 18:20 py27-django-1.3.1
drwxr-xr-x     2 root  wheel       512 Mar 26 18:20
py27-django-extensions-0.8


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/4f92217e/attachment-0001.png>

From f at state-of-mind.de  Thu Mar 29 12:53:37 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Thu, 29 Mar 2012 12:53:37 +0200
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
	<CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
	<CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
Message-ID: <4F743F31.10703@state-of-mind.de>

Hi,

there seems to be a general problem running postorius with Django 1.4.

Postorius alpha1 was released the same day Django 1.4 was, so we haven't
had anyone on the team so far who was running 1.4 while working on
postorius.

@Shayan, could you file a bug on https://launchpad.net/postorius and
paste your traceback into the description field? I will try to get into
it as soon as possible.

Thanks!
Florian




Am 29.03.12 10:51, schrieb Odhiambo Washington:
> On Thu, Mar 29, 2012 at 11:12, Shayan Md <mdoshayan at gmail.com> wrote:
> 
>>
>>
>> On Thu, Mar 29, 2012 at 1:07 PM, Odhiambo Washington <odhiambo at gmail.com>wrote:
>>
>>>
>>>
>>> On Thu, Mar 29, 2012 at 10:33, Shayan Md <mdoshayan at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 29, 2012 at 12:28 PM, Odhiambo Washington <
>>>> odhiambo at gmail.com> wrote:
>>>>
>>>>> On Wed, Mar 28, 2012 at 22:31, Florian Fuchs <f at state-of-mind.de>
>>>>> wrote:
>>>>>
>>>>>> Hi Odhiambo,
>>>>>>
>>>>>> Am 28.03.12 18:47, schrieb Odhiambo Washington:
>>>>>>> One more thing:
>>>>>>>
>>>>>>> In settings.py, I have this:
>>>>>>>
>>>>>>> REST_SERVER = 'http://192.168.40.252:8001'
>>>>>>>
>>>>>>> However, this doesn't seem to be respected when I do runserver:
>>>>>>>
>>>>>>> [root at jaribu] /usr/home/wash/Tools/Mailman/MM3/postorius/dev_setup#
>>>>>>> python manage.py runserver
>>>>>>> Validating models...
>>>>>>>
>>>>>>> 0 errors found
>>>>>>> Django version 1.4, using settings 'dev_setup.settings'
>>>>>>> Development server is running at http://127.0.0.1:8000/
>>>>>>> Quit the server with CONTROL-C.
>>>>>>>
>>>>>>>
>>>>>>> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>>>>>>> root     python     77906 3  tcp4   127.0.0.1:8000
>>>>>>> <http://127.0.0.1:8000>        *:*
>>>>>>> root     python     14108 43 tcp4   127.0.0.1:8001
>>>>>>> <http://127.0.0.1:8001>        *:*
>>>>>>>
>>>>>>> Since I am not using the server as a Desktop, I need a way to
>>>>> access it
>>>>>>> remotely, not via 127.0.0.1
>>>>>>
>>>>>> The REST_SERVER setting defines the location of Mailman's rest API
>>>>>> (which is frequently accessed by postorius), *not* the address of
>>>>>> postorius itself. The API can only be accessed from localhost, so the
>>>>>> setting has to be 'http://localhost:8001'.
>>>>>>
>>>>>> If you'd like to access postorius from a different machine as the one
>>>>>> you're running it on, that's no problem:
>>>>>>
>>>>>> Just run the development server like this and you're good to go:
>>>>>>
>>>>>> python manage.py runserver 192.168.x.xxx:8000
>>>>>>
>>>>>> (Don't do that on a machine that is exposed to the web though, since
>>>>>> Django's dev server is not meant to be run in a production
>>>>> environment.)
>>>>>>
>>>>>> Hope that helps!
>>>>>>
>>>>>> Florian
>>>>>>
>>>>>>
>>>>>
>>>>> My current quest is to see what MM3 web UI looks like, but it appears I
>>>>> am
>>>>> still way behind.
>>>>> I get these errors in the backend when I run posturious and try to
>>>>> access
>>>>> it:
>>>>>
>>>>> http://bit.ly/H2rDuW
>>>>>
>>>> Looks like you didn't start mailman server. Go through this[1] page to
>>>> setup mailman3.
>>>>
>>>> [1]
>>>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>>>
>>>>
>>> Maybe and maybe not, as I was following this very guide!
>>>
>>> [wash at jaribu ~/public_html]$ ps ax | grep mailman
>>> 70295  ??  Is      0:00.40 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/master
>>> 70298  ??  S       0:01.52 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=news:0:1
>>> 70299  ??  S       0:01.57 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=in:0:1
>>> 70300  ??  S       0:01.46 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=digest:0:1
>>> 70301  ??  S       0:01.49 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=pipeline:0:1
>>> 70302  ??  S       0:01.45 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=archive:0:1
>>> 70303  ??  S       0:01.46 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner --runner=out:0:1
>>> 70304  ??  I       0:00.41 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=retry:0:1
>>> 70305  ??  S       0:01.17 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=rest:0:1
>>> 70306  ??  S       0:01.46 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=bounces:0:1
>>> 70307  ??  S       0:00.43 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=lmtp:0:1
>>> 70308  ??  S       0:01.45 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=command:0:1
>>> 70309  ??  S       0:01.50 /usr/local/bin/python
>>> /usr/home/wash/Tools/Mailman/MM3/mailman-3.0.0b1/bin/runner
>>> --runner=virgin:0:1
>>> 78850   1  S+      0:00.01 grep mailman
>>>
>>> Is there something amiss?
>>>
>>>
>>> [root at jaribu] /usr/home/wash# sockstat -l | grep 800
>>> root     python     70442 3  tcp4   192.168.40.252:8000   *:*
>>> root     python     70305 43 tcp4   127.0.0.1:8001        *:*
>>>
>>>
>>> I suppose the 8001 is mailman and 8000 is posturious.
>>
>> Downgrading to django 1.3 might do the trick. Same error here
>> https://answers.launchpad.net/graphite/+question/191549
>>
>>>
>>>
>>>
> Okay. I have to figure out why the consensus is that I am running django
> 1.4 while I actually installed 1.3.1:
> 
> [root at jaribu] /usr/ports/www/py-django# ls -al /var/db/pkg/ | grep django
> drwxr-xr-x     2 root  wheel       512 Mar 26 18:20 py27-django-1.3.1
> drwxr-xr-x     2 root  wheel       512 Mar 26 18:20
> py27-django-extensions-0.8
> 
> 
> 
> 
> 
> _______________________________________________
> 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 f at state-of-mind.de  Thu Mar 29 16:03:07 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Thu, 29 Mar 2012 16:03:07 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
Message-ID: <4F746B9B.5000406@state-of-mind.de>

Am 29.03.12 03:49, schrieb Stephen J. Turnbull:
> To be honest, I don't see how it would be related to Postorius, except
> perhaps as some sort of plug-in (but we don't have a plug-in
> architecture for Postorius, yet).  Adding such features to Postorius
> would be bloat, IMO.  I also worry about the performance hit; I think
> it should probably maintain its own database, etc for the data-mining
> end, and sparingly access the REST client API to update profiles.

It could go into a separate application, but preferably one that could
be hooked into by Postorius. Django already has some kind of
plugin-architecture. It's generally pretty easy to "plug" different apps
together if they follow some simple guidelines for re-usability
(postorius is already using django.contrib.auth and django-social-auth
for instance).

Also, Django allows using multiple databases (even different db-types)
within the same project, so there would be no need to use one database
for everything. (Of course if your db needs are more exotic or beyond
the SQL realm, you're not obliged to use Django's ORM at all.)

Without strongly suggesting any architecture here: I think the relation
to Postorius would be that it currently takes care of authentication and
already holds some user information. So displaying this kind of extended
information within postorius only seemed natural. No matter where this
data is generated from.

I'm not advocating to bloat Postorius, but to use Django. :-)

> 
>> Yes, those would all be very interesting pieces of data.
> 
> To stalkers and Tom Clancy's favorite folks, as well as to nicer
> people.  Make sure there are opt-outs for users.

We talked about that at the PyCon sprint a little. If Postorius displays
more detailed user information the privacy defaults should be pretty
strict. Rather an opt-in than an opt-out. And possibly even more
fine-grained, something like: "Show this piece of information only to:
me - other list members - everyone"... or similar.

Florian




From stephen at xemacs.org  Thu Mar 29 16:46:20 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 29 Mar 2012 23:46:20 +0900
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <20120328190747.3a2c3a66@resist.wooz.org>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
Message-ID: <CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>

On Thu, Mar 29, 2012 at 8:07 AM, Barry Warsaw <barry at list.org> wrote:

> Mailman 3 itself requires unique Message-IDs.

So?  FWIW, I don't think I agree with that requirement (even RFC 5322
doesn't make it a "MUST"), but I'm not going to argue with you about
Mailman 3 design, that's your pidgin.  But there's nothing
particularly Mailman-3-dependent about archiver web UIs, though.  I
don't see any reason why the front end shouldn't be used on my several
gigs of personal archives going back to about 1980, eg, or as a poor
man's webmail.

>?IIRC, the Mail Archive guys
> found a very very low collision rate over millions of messages, and I think
> all such cases were basically spam.

Sure, but XEmacs archives go back to at least 1994.  mailarchive.com
is a more recent phenomenon.  In the early days of Linux/*BSD
diffusion, there were lots of buggy MUAs/very simple MTAs out there.

>>hash ID, and YY... are the remaining ones). ?But it could easily be backed by
>>an IMAP store or something more specialized; we don't really care as long as
>>it's object-ID-addressable.
>
> Don't forget too that the LMTP runner automatically adds the X-Message-ID-Hash
> header, which is a Base32 encoding of the SHA1 hash of the Message-ID contents
> (without the angle brackets). ?This hash could be used as well.

It doesn't do that for subobject content IDs, and more important,
users don't necessarily have the X-Message-ID-Hash (they may have
not-metoo set, they may have gotten the message as a direct Cc).
True, it's easy enough to compute -- if you're a Mailman 3 developer
and know it's present.<wink/>  And, of course, why have a Mailman 3
dependency that is absolutely unnecessary?

From a.badger at gmail.com  Thu Mar 29 16:53:11 2012
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Mar 2012 07:53:11 -0700
Subject: [Mailman-Developers] Additional Mailman GSoC mentors
In-Reply-To: <4F7415CF.20304@zone12.com>
References: <4F7415CF.20304@zone12.com>
Message-ID: <20120329145310.GE11151@unaka.lan>

On Thu, Mar 29, 2012 at 01:57:03AM -0600, Terri Oda wrote:
> It's looking like we're going to have more student applicants than in
> previous years, so I think it'd be great if we could get a few more
> mentors to match.
> 
> If you're a semi-active mailman developer (i.e. I'm going to
> recognize your name from your mailman-developers postings) and you
> think you might interested in mentoring for GSoC this summer or just
> want to know what's involved, please get in touch with me!
> 
I'm willing to help mentor some work.  I'd really like to mentor with
some other people -- especially at the application review stages -- I do
have more time for day-to-day mentoring if that's done on IRC (Interrupt
Driven Design, anyone ;-)  But so far, my knowledge of the mailman codebase
is limited mainly to archiver stuff.

I can answer questions about using bzr and some launchpad questions
(although I also have lots of launchpad questions of my own :-).  I'm now
fully versed in Warsaw import style rules although I should probably
recertify at the next pycon :-)

It does seem like there's a lot of interest in archivers this year (at
least, people have been pinging me about that.  Since archivers for mailman3
are somewhat in their infancy, it would be good to think of a "what do we
want the state of archivers to be after the summer and a year from now" so
that we can make sure that GSoC work fits into that.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/8d66e616/attachment-0001.pgp>

From barry at list.org  Thu Mar 29 17:03:11 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 29 Mar 2012 11:03:11 -0400
Subject: [Mailman-Developers] Additional Mailman GSoC mentors
In-Reply-To: <20120329145310.GE11151@unaka.lan>
References: <4F7415CF.20304@zone12.com>
	<20120329145310.GE11151@unaka.lan>
Message-ID: <20120329110311.19c3a4d5@resist.wooz.org>

On Mar 29, 2012, at 07:53 AM, Toshio Kuratomi wrote:

>I can answer questions about using bzr and some launchpad questions
>(although I also have lots of launchpad questions of my own :-).  I'm now
>fully versed in Warsaw import style rules although I should probably
>recertify at the next pycon :-)

Anybody else want to take the 300 page quiz on that?

:)

>It does seem like there's a lot of interest in archivers this year (at
>least, people have been pinging me about that.  Since archivers for mailman3
>are somewhat in their infancy, it would be good to think of a "what do we
>want the state of archivers to be after the summer and a year from now" so
>that we can make sure that GSoC work fits into that.

+1

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/a01adf05/attachment.pgp>

From barry at list.org  Thu Mar 29 17:17:01 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 29 Mar 2012 11:17:01 -0400
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
	<CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
Message-ID: <20120329111701.39c2fca1@resist.wooz.org>

(Aside: Is there some reason why you To: me and CC: the list rather than
having the list address in the To: field?  I ask because I'm wondering if it's
a gmail thing, or something about your MUA, and because I suppress the list
copy if I'm CC'd directly, I don't get a List-Post: header, so my MUA's
reply-to-list won't work on your messages.  I'm mostly curious because I can
work around it as you see here, but just wanted to point it out in case you
weren't aware of it and/or could easily fix it -- if you even agree it's
broken. ;)

On Mar 29, 2012, at 11:46 PM, Stephen J. Turnbull wrote:

>On Thu, Mar 29, 2012 at 8:07 AM, Barry Warsaw <barry at list.org> wrote:
>
>> Mailman 3 itself requires unique Message-IDs.
>
>So?  FWIW, I don't think I agree with that requirement (even RFC 5322
>doesn't make it a "MUST"), but I'm not going to argue with you about
>Mailman 3 design, that's your pidgin.

We had a fairly lengthy discussion about this a year or so ago, and I'm pretty
sure we came to the consensus (even if not unanimous) that it was reasonable
for Mailman to impose this restriction.  It's 2012 so if your MUA/MTA can't
generate unique message id's there's no reason for us to think you're not a
spammer <wink>.

>But there's nothing particularly Mailman-3-dependent about archiver web UIs,
>though.  I don't see any reason why the front end shouldn't be used on my
>several gigs of personal archives going back to about 1980, eg, or as a poor
>man's webmail.

True, the archiver as an independent component can be more lenient.  I'm just
pointing out that as fed from Mailman, it will only get unique message ids.
And if it doesn't, that's a bug in Mailman.

>>?IIRC, the Mail Archive guys found a very very low collision rate over
>> millions of messages, and I think all such cases were basically spam.
>
>Sure, but XEmacs archives go back to at least 1994.  mailarchive.com
>is a more recent phenomenon.  In the early days of Linux/*BSD
>diffusion, there were lots of buggy MUAs/very simple MTAs out there.

Sure.  And I suspect that there will be plenty of mailing lists that get fed
messages from programs, e.g. think vcs -commit diff lists.  Those programs can
also be buggy, but again I'd prefer that Mailman not compromise on this issue
for their sake.

>It doesn't do that for subobject content IDs, and more important,
>users don't necessarily have the X-Message-ID-Hash (they may have
>not-metoo set, they may have gotten the message as a direct Cc).
>True, it's easy enough to compute -- if you're a Mailman 3 developer
>and know it's present.<wink/>  And, of course, why have a Mailman 3
>dependency that is absolutely unnecessary?

Right.  The point being that messages that flow through Mailman will have that
hash in the message URLs in the Archived-At header and possibly in the
decorated footers.  An archiver should certainly provide an interface to look
up a message by pure Message-ID or the hash.  The hash is just a scheme to
regularize the message id and is a tiny fraction more user-friendly (because
of its limited alphabet and manageable, known-in-advance length).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/f9142bdd/attachment.pgp>

From richard at NFSNet.org  Thu Mar 29 18:06:44 2012
From: richard at NFSNet.org (Richard Wackerbarth)
Date: Thu, 29 Mar 2012 11:06:44 -0500
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <20120329111701.39c2fca1@resist.wooz.org>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
	<CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
	<20120329111701.39c2fca1@resist.wooz.org>
Message-ID: <EC151C0E-4378-4059-96F4-8ADF8187EF14@NFSNet.org>

On Mar 29, 2012, at 10:17 AM, Barry Warsaw wrote:

> (Aside: Is there some reason why you To: me and CC: the list rather than
> having the list address in the To: field?  I ask because I'm wondering if it's
> a gmail thing, or something about your MUA, and because I suppress the list
> copy if I'm CC'd directly, I don't get a List-Post: header, so my MUA's
> reply-to-list won't work on your messages.

> On Mar 29, 2012, at 11:46 PM, Stephen J. Turnbull wrote:

<snip>

Barry,

I would guess that it is a MUA thing.

I received, (from the list):
	From: 	Barry Warsaw <barry at list.org>
	To: 		Stephen J. Turnbull <stephen at xemacs.org>
	Cc: 		Mailman Developer List <mailman-developers at python.org>
<snip>

If I select "Reply All:, my MUA (OSX Mail 4.5) generates:
	From:	Richard Wackerbarth<richard at NFSNet.org>
	To:		Barry Warsaw <barry at list.org>
	Cc: 		Stephen J. Turnbull <stephen at xemacs.org>, Mailman Developer List <mailman-developers at python.org>
<snip>

I them (manually) altered the headers to sent this only to the list.

Richard

From odhiambo at gmail.com  Thu Mar 29 18:12:22 2012
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Thu, 29 Mar 2012 19:12:22 +0300
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <4F743F31.10703@state-of-mind.de>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
	<CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
	<CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
	<4F743F31.10703@state-of-mind.de>
Message-ID: <CAAdA2WPRfZ_zapuA_3yqfsXuHGs7tjixnbbvt-vig_4n7X6Lfg@mail.gmail.com>

On Thu, Mar 29, 2012 at 13:53, Florian Fuchs <f at state-of-mind.de> wrote:

> Hi,
>
> there seems to be a general problem running postorius with Django 1.4.
>
> Postorius alpha1 was released the same day Django 1.4 was, so we haven't
> had anyone on the team so far who was running 1.4 while working on
> postorius.
>
>
@Florian,

My issue here is that I am not running Django 1.4 - unless I am missing
something. I am not sure where it is coming from.
I am on FreeBSD and I installed django-1.3.1 from the ports. A check on my
installed apps shows just that. There is a port for py-django-devel but I
did not install that at all:

See this

[root at jaribu] /usr/ports/www/py-django-devel# make fetch

===>  py27-django-devel-17269,1 conflicts with installed package(s):
      py27-django-1.3.1

      They install files into the same place.
      You may want to stop build with Ctrl + C.
===>  License check disabled, port has not defined LICENSE
=> Django-r17269.tar.xz doesn't seem to exist in
/usr/ports/distfiles/python.
=> Attempting to fetch
http://people.cs.nctu.edu.tw/~lwhsu/ports/distfiles/Django-r17269.tar.xz
Django-r17269.tar.xz                           85% of 4135 kB  135 kBps
00m04s

That shows I have django-1.3.1 installed.

I went as far as this:
 `mv /usr/local/lib/python2.7/site-packages/django
/usr/local/lib/python2.7/site-packages/_django-1.4`
Then reinstalled django-1.3.1, but I am pretty sure that the above action
wasn't necessary.

So I wiped put everything - python, django, mailman, mailman.client,
py-sqlite3 - and reinstalled. Mailman gave me enough grief
with bin/test and I had to wipe and reinstall several times. Perhaps it
wasn't getting all the files during bin/build.

Now things look promising, but I still get errors about some templates I
need to create - 500.html, 400.html....


Traceback (most recent call last):

  File "/usr/local/lib/python2.7/site-packages/django/core/servers/basehttp.py",
line 283, in run
    self.result = application(self.environ, self.start_response)

  File "/usr/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py",
line 272, in __call__
    response = self.get_response(request)

  File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py",
line 169, in get_response
    response = self.handle_uncaught_exception(request, resolver, sys.exc_info())

  File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py",
line 218, in handle_uncaught_exception
    return callback(request, **param_dict)

  File "/usr/local/lib/python2.7/site-packages/django/utils/decorators.py",
line 93, in _wrapped_view
    response = view_func(request, *args, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/django/views/defaults.py",
line 30, in server_error
    t = loader.get_template(template_name) # You need to create a
500.html template.

  File "/usr/local/lib/python2.7/site-packages/django/template/loader.py",
line 157, in get_template
    template, origin = find_template(template_name)

  File "/usr/local/lib/python2.7/site-packages/django/template/loader.py",
line 138, in find_template
    raise TemplateDoesNotExist(name)

TemplateDoesNotExist: 500.html



How do  I create these and where do I place them? Where is the guide??



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120329/7ebd42fc/attachment-0001.png>

From stephen at xemacs.org  Thu Mar 29 18:16:34 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 01:16:34 +0900
Subject: [Mailman-Developers] mailman / archive-ui / licensing questions
In-Reply-To: <CA+CP9O48F8FXr5ya4_z=g3jPujs=c=_30=9O0Np0iCpFjibt0w@mail.gmail.com>
References: <CA+CP9O48F8FXr5ya4_z=g3jPujs=c=_30=9O0Np0iCpFjibt0w@mail.gmail.com>
Message-ID: <CAL_0O18Hytf3yP5xcVm+Xp4yPzPM69akPf=fSMZUT0vn9u-vZw@mail.gmail.com>

On Thu, Mar 29, 2012 at 1:00 PM, David Jeske <davidj at gmail.com> wrote:

> I started to talk to one of them about installing CSLA (or MHonArc, or
> anything really), and realized I should see if you folks are interested in
> a great bundled archiver,

I'm personally interested, but that's not going to be the main focus
until the core gets a little less alpha, I would guess.

> I admit that even with a pretty good knowledge of these many licenses, I'm
> not familiar with the intracacies of FSF copyright assignment and non-GPL
> free licenses.

The bottom line is that if you assign it to the FSF, they can change
the license of future copies to something you don't like without your
permission, or even consulting you.  This has been done in the past
(eg, libreadline).  I don't know whether they would bother with a
non-GNU project, though.

However, copies of the version you originally released under a
different license remain under that license, and there's always a
grant-back clause in the assignment contract that allows you to make
derivatives of your contributions available under any license you
like.

> The ClearsilverArchiver code (written by me and two others) is released
> under the "Simplified BSD" license and "totally free".  It's important to me
> that any code I release be similarly free-and-unrestricted
> (i.e. BSD/Python/Artistic/PublicDomain), not free under certain conditions
> (i.e. GPL/LGPL). It's not possible to assert GPL restrictions on
> totally-free code, because it's already totally free.

That's not the way copyright works, though.  It certainly is possible
to assert GPL (or any other) restrictions on given *copies* of
permissively-licensed code.  If you've got a copy of the old (say,
early '90s) O'Reilly "X Window System" series kicking around, check
out the copyright notice in those books.  (Preventing that is
precisely why copyleft advocates advocate copyleft.)  Even on a
verbatim copy, lawyerly FUD means that even if there is no actual
legal issue, practically it may be infeasible for just plain folks to
redistribute.  Cf. the DMCA takedowns.

> FSF says S-BSD is GPL-Compatible, which I believe means they are saying
> they have no problem with GPL code depending on and being combined with
> (i.e. linked with) S-BSD code, because the S-BSD code is fully open-source
> and does not put restrictions on the use of the GPL code.

No.  What they mean is that it is Borg-able.  You can assimilate S-BSD
code into a GPL project, and that copy is distributed under the GPL.
Perhaps in legal theory they cannot prevent you from making copies of
the S-BSD portions and doing anything the S-BSD permits, but the S-BSD
(like other permissive licenses) does not require them to tell you
what parts are S-BSD, only that some parts are, and who wrote those
(unspecified) parts.  (The wording is generally to the effect of "This
file is part of the FOO Program, which is licensed to you under the
GPL.  It contains software by J. Random Hacker, with the following
permissions notice...".)  The burden will be on the user to determine
which parts can and cannot be copied, and if it comes to a court case,
the user will have to prove that the parts they've copied are not
actually GPL.

I would say you should try to retain copyright, and have the Mailman
project distribute it with the S-BSD license under the "mere
aggregation" clause of the GPL.  This would entail certain
restrictions on interface.  Eg, you can't put the whole thing in a
pipeline Handler, and you would need to have a separate webapp for
summarizing/indexing/searching/retrieving the archived posts.  I
advocate those restrictions anyway. :-)  Some small glue parts that
need to be tightly integrated with core Mailman might need to be done
under GPL.

> It's also my understanding that the primary reason for FSF copyright
> assignment is to provide a coherent entity to enforce the terms of the GPL
> by challenging violators who don't redistribute source.... something which
> is not necessary for S-BSD. (Though I suppose they could enforce that folks
> include the S-BSD copyright notices.)

The FSF's reason is so that they have control over the license, which
allows them to make it GPL if that seems like a good idea to them.
(Mostly they are way too busy to go looking for opportunities, though,
and it's a labor-intensive process for a project of any size.)  In
return, they will enforce license provisions.

Projects may also wish to do this so that they have the legal right to
offer other licenses (the FSF is not a good assignee for this
purpose!), or change the primary license.  If no single entity owns
the whole copyright, then you have to get agreement of all owners,
some of whom may be in retreat in a Tibetan monastery or the heirs to
someone who lost an argument with a bus, etc.  (MIT specifically
allows sublicensing, as does Larry Rosen's AFT; but S-BSD does not.)

> Is Mailman-team is interested in having a better built-in archiver that is
> included in the distribution, but licensed under the less-restrictive S-BSD
> terms?

I certainly would be interested!  (I believe that freedom can only be
preserved by the blood and legal fees of patriots, while GPL isn't
much help any more, and increasingly frequently a PITA. :-)  Other
folks prefer to license their work under copyleft, specifically the
GPL.  But there's explicit permission in the GPL for such distribution
(the "mere aggregation" clause), as long as communication between the
archiver and core Mailman is done by open protocols such as *MTP and
maildir.  (Ie, the included Handler and IArchive integration code will
probably be GPL, but there's no need for anything in a separate
process, including indexing and web UI, to be GPL.)

From stephen at xemacs.org  Thu Mar 29 18:21:53 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 01:21:53 +0900
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CA+CP9O4hHRjVboe6wBRg+juRAJWA1Utiyu0Kxz1RVAL+jbRcdw@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327182908.573b8c96@resist.wooz.org>
	<CA+CP9O4hHRjVboe6wBRg+juRAJWA1Utiyu0Kxz1RVAL+jbRcdw@mail.gmail.com>
Message-ID: <CAL_0O194i_hQNRizHxd1+sPJU7QVKch4NQ7iYE5W86_zXyZs_Q@mail.gmail.com>

On Thu, Mar 29, 2012 at 4:04 PM, David Jeske <davidj at gmail.com> wrote:
>> - Merging of forums, archives, newsgroups, and IMAP.
>
> You like to bite off the big ones eh? NNTP, then IMAP.
>
> Does anyone even use fat-mail-clients anymore?

Yes, and yes.  But I don't think anybody has really thought carefully
about these desiderata yet, they're just frequently suggested on
mailman-users and sometimes mailman-developers.

From f at state-of-mind.de  Thu Mar 29 18:47:49 2012
From: f at state-of-mind.de (Florian Fuchs)
Date: Thu, 29 Mar 2012 18:47:49 +0200
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WPRfZ_zapuA_3yqfsXuHGs7tjixnbbvt-vig_4n7X6Lfg@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
	<CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
	<CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
	<4F743F31.10703@state-of-mind.de>
	<CAAdA2WPRfZ_zapuA_3yqfsXuHGs7tjixnbbvt-vig_4n7X6Lfg@mail.gmail.com>
Message-ID: <4F749235.8040307@state-of-mind.de>

Hi Odhiambo,

Am 29.03.12 18:12, schrieb Odhiambo Washington:
> My issue here is that I am not running Django 1.4 - unless I am missing
> something. I am not sure where it is coming from.
> I am on FreeBSD and I installed django-1.3.1 from the ports. A check on my
> installed apps shows just that. There is a port for py-django-devel but I
> did not install that at all:
> 
> See this
> 
> [root at jaribu] /usr/ports/www/py-django-devel# make fetch
> 
> ===>  py27-django-devel-17269,1 conflicts with installed package(s):
>       py27-django-1.3.1
> 
>       They install files into the same place.
>       You may want to stop build with Ctrl + C.
> ===>  License check disabled, port has not defined LICENSE
> => Django-r17269.tar.xz doesn't seem to exist in
> /usr/ports/distfiles/python.
> => Attempting to fetch
> http://people.cs.nctu.edu.tw/~lwhsu/ports/distfiles/Django-r17269.tar.xz
> Django-r17269.tar.xz                           85% of 4135 kB  135 kBps
> 00m04s
> 
> That shows I have django-1.3.1 installed.
> 
> I went as far as this:
>  `mv /usr/local/lib/python2.7/site-packages/django
> /usr/local/lib/python2.7/site-packages/_django-1.4`
> Then reinstalled django-1.3.1, but I am pretty sure that the above action
> wasn't necessary.

Generally, *if* you have multiple versions installed and want to know
which version is actually imported, cd to postorius/dev_setup, open up a
Python shell and try the following:

 >>> import django
 >>> django.__file__  # prints the package path
 >>> django.VERSION   # prints the django version

> 
> So I wiped put everything - python, django, mailman, mailman.client,
> py-sqlite3 - and reinstalled. Mailman gave me enough grief
> with bin/test and I had to wipe and reinstall several times. Perhaps it
> wasn't getting all the files during bin/build.
> 
> Now things look promising, but I still get errors about some templates I
> need to create - 500.html, 400.html....
> 
> 
> Traceback (most recent call last):
> 
>   File "/usr/local/lib/python2.7/site-packages/django/core/servers/basehttp.py",
> line 283, in run
>     self.result = application(self.environ, self.start_response)
> 
>   File "/usr/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py",
> line 272, in __call__
>     response = self.get_response(request)
> 
>   File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py",
> line 169, in get_response
>     response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
> 
>   File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py",
> line 218, in handle_uncaught_exception
>     return callback(request, **param_dict)
> 
>   File "/usr/local/lib/python2.7/site-packages/django/utils/decorators.py",
> line 93, in _wrapped_view
>     response = view_func(request, *args, **kwargs)
> 
>   File "/usr/local/lib/python2.7/site-packages/django/views/defaults.py",
> line 30, in server_error
>     t = loader.get_template(template_name) # You need to create a
> 500.html template.
> 
>   File "/usr/local/lib/python2.7/site-packages/django/template/loader.py",
> line 157, in get_template
>     template, origin = find_template(template_name)
> 
>   File "/usr/local/lib/python2.7/site-packages/django/template/loader.py",
> line 138, in find_template
>     raise TemplateDoesNotExist(name)
> 
> TemplateDoesNotExist: 500.html

Django tries to find a 500.html file to display a standard error page.
It cannot find one and raises TemplateDoesNotExist. But the more
important question is: What's the actual cause for the 500 internal
server error?

IIRC Django only looks for a 500.html in non-DEBUG mode, so my guess is
that your DEBUG setting in dev_setup/settings.py is set to False. If
that is the case a good next step would be to set it to True and have a
look at the traceback again - it should be much more detailed than the
one you're seeing right now and (hopefully) give us a clue what's
actullay going wrong.

If you like paste the traceback to some of the various pasters out there
(like paste.ubuntu.com) and post the link to it here - it's much easier
to read then.

Florian


> 
> 
> 
> How do  I create these and where do I place them? Where is the guide??
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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 dgc at uchicago.edu  Thu Mar 29 18:54:06 2012
From: dgc at uchicago.edu (David Champion)
Date: Thu, 29 Mar 2012 11:54:06 -0500
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <CAL_0O194i_hQNRizHxd1+sPJU7QVKch4NQ7iYE5W86_zXyZs_Q@mail.gmail.com>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327182908.573b8c96@resist.wooz.org>
	<CA+CP9O4hHRjVboe6wBRg+juRAJWA1Utiyu0Kxz1RVAL+jbRcdw@mail.gmail.com>
	<CAL_0O194i_hQNRizHxd1+sPJU7QVKch4NQ7iYE5W86_zXyZs_Q@mail.gmail.com>
Message-ID: <20120329165406.GD7658@scurvy.bikeshed.us>

* On 29 Mar 2012, Stephen J. Turnbull wrote: 
> On Thu, Mar 29, 2012 at 4:04 PM, David Jeske <davidj at gmail.com> wrote:
> >> - Merging of forums, archives, newsgroups, and IMAP.
> >
> > You like to bite off the big ones eh? NNTP, then IMAP.
> >
> > Does anyone even use fat-mail-clients anymore?
> 
> Yes, and yes.  But I don't think anybody has really thought carefully
> about these desiderata yet, they're just frequently suggested on
> mailman-users and sometimes mailman-developers.

+1

For what it's worth: I bridged MM archives to IMAP once using UW imapd
and some scripts for proxying Mailman membership data into something
that imapd could use for access control.  When I presented it to this
list it was generally identified as something nobody (w|sh)ould ever
want.  I don't care particularly about the details of what happened in
2002 or whenever it was, but I conclude that the much bigger problem
than building this ship is choosing a destination.  It needs to start
with clear goals, because the wrong implementation is easy.

-- 
David Champion ? dgc at uchicago.edu ? IT Services ? University of Chicago

From stephen at xemacs.org  Thu Mar 29 19:18:02 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 02:18:02 +0900
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <20120329111701.39c2fca1@resist.wooz.org>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
	<CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
	<20120329111701.39c2fca1@resist.wooz.org>
Message-ID: <CAL_0O18dKrHBrPGv4YbNnWQpX0-DMQH8m+UKquE24mUy4np5nA@mail.gmail.com>

>>>> Barry writes:

> I suspect that there will be plenty of mailing lists that get fed
> messages from programs, e.g. think vcs -commit diff lists. ?Those programs can
> also be buggy, but again I'd prefer that Mailman not compromise on this issue
> for their sake.

I predict you will eventually lose on this.  That's not an argument
for changing, of course. :-)

> The point being that messages that flow through Mailman will have that
> hash in the message URLs in the Archived-At header and possibly in the
> decorated footers. ?An archiver should certainly provide an interface to look
> up a message by pure Message-ID or the hash. ?The hash is just a scheme to
> regularize the message id and is a tiny fraction more user-friendly (because
> of its limited alphabet and manageable, known-in-advance length).

I would say that's actually quite significant, because the trash that
I've observed in message-ids is varied, to be polite.  It will be nice
to be able to avoid URL-escaping, RFC 2047 soft line breaks, and all
the rest.

From terri at zone12.com  Thu Mar 29 20:40:51 2012
From: terri at zone12.com (Terri Oda)
Date: Thu, 29 Mar 2012 12:40:51 -0600
Subject: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and
 Postorius 1.0 alpha 1
In-Reply-To: <CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
References: <20120323220013.0b1c88a8@resist.wooz.org>
	<CAL_0O1_1NNt7hDPZEZ17LFnkewdH5-jfJAedTwQJPzU2BoJW7w@mail.gmail.com>
	<CAHjiUbrQLbevLxJU3_XjYADAQi4kBwYHXF5z3Kp1h_g+4DFffQ@mail.gmail.com>
	<CAAdA2WOvP=cwzoVNrWkDscHtPb7wk-G-t6u-moZKFnxpxPHNbA@mail.gmail.com>
	<4F7338BD.70501@state-of-mind.de>
	<CAAdA2WP16r=zA=fgpohvYJzbU_gxXF3D40o5ms-cjYmNw-fy3g@mail.gmail.com>
	<CAAdA2WOmZuSg7ABK6Mtv5u=C2EZ+2n-aREVg97nQee8Ec09iQw@mail.gmail.com>
	<4F73671A.4090700@state-of-mind.de>
	<CAAdA2WNhrSgU88_eVz=wNzi12_xM4X39XcMUWv5GBmTFUuAGqQ@mail.gmail.com>
	<CAKfaKcM7nEafNB2Sq0Gv0P1oK+0TN4wHn6zZgg+rPt4Gks=OcA@mail.gmail.com>
	<CAAdA2WM3rJATHbWtiLTaOq5JngxGb=G1MH=c-zAvT7oc7kNQAQ@mail.gmail.com>
	<CAKfaKcPt=a74_oGbjqfx_=uNZFZJqghDjB34nrLRsryO1ADbqQ@mail.gmail.com>
	<CAAdA2WMqTVW0PXVww_uwymMTTcRAvysZ2c5NUmzGNd4w6=+ECw@mail.gmail.com>
Message-ID: <4F74ACB3.5080303@zone12.com>

On 03/29/2012 02:51 AM, Odhiambo Washington wrote:

> Okay. I have to figure out why the consensus is that I am running django
> 1.4 while I actually installed 1.3.1:


Just for the record, the reason we suspect Django 1.4 conflicts is that 
the link you posted with the errors 
<http://196.200.26.114/~wash/mailman-error.txt> was tossing a lot of 
errors that came from a Django-1.4 package.  For example:


  File 
"/usr/local/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/core/handlers/base.py", 
line 179, in get_response
     response = self.handle_uncaught_exception(request, resolver, 
sys.exc_info())

That rather implies that it was using some pieces that were not 1.3.1, 
which could account for the errors.

  Terri


From mdoshayan at gmail.com  Thu Mar 29 20:55:50 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Fri, 30 Mar 2012 00:25:50 +0530
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
Message-ID: <CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>

On Wed, Mar 28, 2012 at 6:59 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda <terri at zone12.com> wrote:
>
> >> Looks like archiver for mm3 is still in development stage. As far as I
> >> understand searcher depends on the srchiver, right? Not completely but
> it
> >> somewhat depends on archiver. I am not sure if searcher can be
> implemented
> >> without archiver. If possible I can implement for mm3 also.
> >
> > Searcher and archiver are interdependent *if* we want to share caches and
> > data stores, which we probably do for any installation with larger
> archives
> > where storing 2 copies vs 4 of each message would make a difference.
>  Plus,
> > many archive views may be basically searches "messages in the last month"
> > "messages which are replies to messageid $foo" etc.
>
> Actually, as far as I can see, the summary/search/index/retrieval
> functions depend only on the API for the message store.  If you
> want, you can split this into the database layer and a presentation
> layer, of course.  However, the database layer is surely going to
> have its own schema optimized for the kinds of retrieval its
> designer considers important.  If the designer emphasizes
> threads, however, she is *not* going to try to store messages in
> thread order or anything like that.  Rather, any reasonable store
> will be message-ID-addressable.
>
> The only tricky issue is that we *do* have to worry about
> message-ID collisions of truly different messages and about
> messages without message IDs, especially for converted
> historical archives.  So the API needs to be able to deal
> with these issues, probably by returning a set or sequence
> of messages.
>
> Oh, and we probably ought to have a more general notion
> of retrievable "object" rather than just messages, as some
> archive/retrieval backends may store some types of MIME
> part separately.  Hopefully these would be presented to
> us as MIME parts with external bodies and content IDs.
>
> I would guess she'll probably store messages in
> YY-MM/MSGID, or as git does in "unpacked"
> XX/YYYYYYYY... format, where XX are the first two digits
> of the hash ID, and YY... are the remaining ones).  But it
> could easily be backed by an IMAP store or something
> more specialized; we don't really care as long as it's
> object-ID-addressable.
>

Assuming that we have something like this(object-ID-addressable, If I am
not wrong, mailman3 made it possible but not yet implemented as it's part
of archiver), is it over ambitious to plan to implement indexer/searcher
for mailman3 and a REST API to use this searcher, extend client to use this
api,
and django search form along with this client api? All this independent of
archiver. Because the only part common with archiver is message retrieval
part,
If we implement whole searcher, and rest of the client code, later when
archiver is implemented message retrieval code can used in searcher. When
archiver is completely mature may we can even merge them together. Is it
possible? Or this plan has any 'non-sense' parts?


> And that's all we want to say about the archiver and the
> associated message-retrieval logic, I think.  (In fact, it occurs to
> me that maybe we should say "RFC 3501" and be done with
> it.  I don't mean that we necessarily implement IMAP protocol
> per se, but some subset of its functionality probably is what we
> need from an archiver.)
>
> Then the schema-specific stuff will use hash IDs to represent
> message objects in a portable but schema-specific way.  As
> it's schema-specific, I don't really see how data structures
> can be shared by different searchers.
>
> So I would say not to worry about the archiver side at all.  If
> large installations want to implement specialized message-
> retrieval, bully for them.  But we can go with simple backends,
> maildir, mbox, and maybe IMAP, I think.
> _______________________________________________
> 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/mdoshayan%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From davidj at gmail.com  Thu Mar 29 22:27:57 2012
From: davidj at gmail.com (David Jeske)
Date: Thu, 29 Mar 2012 13:27:57 -0700
Subject: [Mailman-Developers] mailman / archive-ui / licensing questions
In-Reply-To: <CAL_0O18Hytf3yP5xcVm+Xp4yPzPM69akPf=fSMZUT0vn9u-vZw@mail.gmail.com>
References: <CA+CP9O48F8FXr5ya4_z=g3jPujs=c=_30=9O0Np0iCpFjibt0w@mail.gmail.com>
	<CAL_0O18Hytf3yP5xcVm+Xp4yPzPM69akPf=fSMZUT0vn9u-vZw@mail.gmail.com>
Message-ID: <CA+CP9O4LZuwPHATTUQdDo68c1h3MvtZoHjFJowmHfCdizcGmqQ@mail.gmail.com>

On Thu, Mar 29, 2012 at 9:16 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> I would say you should try to retain copyright, and have the Mailman
> project distribute it with the S-BSD license under the "mere
> aggregation" clause of the GPL.


This agrees with my view of the situation as well. Which leads to the
question, is the above approach interesting/viable for Mailman-team?
(assuming the code does something awesome that people want)

That's not the way copyright works, though.  It certainly is possible
> to assert GPL (or any other) restrictions on given *copies* of
> permissively-licensed code.


What they mean is that it is Borg-able.  You can assimilate S-BSD
> code into a GPL project, and that copy is distributed under the GPL.
>

My response here is just academic license-logic evaluation for
entertainment purposes...

I know you can "claim" to assert GPL restrictions on copies of S-BSD
code. I just don't understand how it could ever be enforced.

Any changes made post "assimilation" would be in a state of confusion WRT
GPL-restrictability. Even FSF-copyright assignment for those changes isn't
sufficient to prove that the initial developer never gave a less-restricted
version of his changes out directly to the S-BSD pre-assimilation project
under their license. You're back to requiring afadavits from all authors
stating they never did so, or perhaps challenging projects to produce
checkin-logs to show who saw the change first.

...the thought experiment is merely academic though. I don't want my code
in the hands of folks that can even "claim" to restrict it with the GPL..
which means FSF-assignment is not something I'm willing to do for my stuff.

From stephen at xemacs.org  Fri Mar 30 01:35:33 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 08:35:33 +0900
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>
Message-ID: <CAL_0O196TmaOAZW3sU4xfMK1=Fp2bsY3o2AYX5ekWx3qVKhC2Q@mail.gmail.com>

On Fri, Mar 30, 2012 at 3:55 AM, Shayan Md <mdoshayan at gmail.com> wrote:

> Assuming that we have something like this(object-ID-addressable, If I am
> not wrong, mailman3 made it possible but not yet implemented as it's part
> of archiver), is it over ambitious to plan to implement indexer/searcher
> for mailman3 and a REST API to use this searcher, extend client to use this
> api,
> and django search form along with this client api? All this independent of
> archiver. Because the only part common with archiver is message retrieval
> part,
> If we implement whole searcher, and rest of the client code, later when
> archiver is implemented message retrieval code can used in searcher. When
> archiver is completely mature may we can even merge them together. Is it
> possible? Or this plan has any 'non-sense' parts?

Hi, Shayan.  It's not nonsense, but (1) how do you propose to test if
you have no archives to run it on?  And (2) search and retrieval may
do a *lot* of message access, for example if you want to do data
mining (see Ana from Spain's thread).  In that case, you may find that
maildir imposes too many stats, which are very expensive on some
platforms (and not cheap on any that I know of) and mbox requires too
large memory.  So for some purposes a summary/index/search engine may
want an optimized message store.

Those may not be your purposes, of course, in which case a simple mbox
accessor and a download of a couple of mboxes from any public Mailman
list will give you test fodder.

Testing itself is not really a matter of personal preference.
Although Mailman is not a 100% test-driven shop, Mailman 3 already has
a *lot* of tests and Barry would like to see any new modules covered,
I'm sure.  Also, this area is fraught with pitfalls for the developer.
 See this thread, for example:
http://thread.gmane.org/gmane.comp.python.devel/131395/focus=131406.

From pingou at pingoured.fr  Thu Mar 29 21:48:50 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Thu, 29 Mar 2012 21:48:50 +0200
Subject: [Mailman-Developers] any interest in a new built-in
 web-archive? (i.e. pipermail replacement)
In-Reply-To: <20120327001152.GY11151@unaka.lan>
References: <CA+CP9O5gv9pCqcGC6_+ttt1p7axazkfXmgV+vD+0nmjkec31jQ@mail.gmail.com>
	<20120327001152.GY11151@unaka.lan>
Message-ID: <1333050530.17059.5.camel@ambre.pingoured.fr>

On Mon, 2012-03-26 at 17:11 -0700, Toshio Kuratomi wrote:
> Grackle is another archiver for mailman that doesn't
> have the UI bells and whistles of hyperkitty but it does make an
> effort to expose a REST UI to the world.  I think that's a beautiful
> thing.  

I started a small thing on hyperkitty there:
http://mm3test.fedoraproject.org/api/

Pierre

From jeff at jab.org  Fri Mar 30 05:02:57 2012
From: jeff at jab.org (Jeff Breidenbach)
Date: Thu, 29 Mar 2012 20:02:57 -0700
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <20120329111701.39c2fca1@resist.wooz.org>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
	<CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
	<20120329111701.39c2fca1@resist.wooz.org>
Message-ID: <CAHjiUbqf+_AXt9Awfs0wk=Y5WRN8oeD+J+2p6YKmrd5=URKFjg@mail.gmail.com>

> An archiver should certainly provide an interface to look up a message by [...] the hash.

Including List-Id in the hash calculation allows the archiver to
display a cross
posted message in context. See http://www.mail-archive.com/faq.html#listserver

Also,  a gentle reminder that I put some comments in the Launchpad entry
for IMailingList.archive*

Jeff

From barry at list.org  Fri Mar 30 05:15:24 2012
From: barry at list.org (Barry Warsaw)
Date: Thu, 29 Mar 2012 23:15:24 -0400
Subject: [Mailman-Developers] Google Summer of Code: Integration of
 Search Code
In-Reply-To: <CAL_0O18dKrHBrPGv4YbNnWQpX0-DMQH8m+UKquE24mUy4np5nA@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<20120328190747.3a2c3a66@resist.wooz.org>
	<CAL_0O193FerH+pevU1VNJpSMYUzMzhL2us8HHEFJtTwAbnR90A@mail.gmail.com>
	<20120329111701.39c2fca1@resist.wooz.org>
	<CAL_0O18dKrHBrPGv4YbNnWQpX0-DMQH8m+UKquE24mUy4np5nA@mail.gmail.com>
Message-ID: <20120329231524.1552f99d@resist.wooz.org>

On Mar 30, 2012, at 02:18 AM, Stephen J. Turnbull wrote:

>> I suspect that there will be plenty of mailing lists that get fed messages
>> from programs, e.g. think vcs -commit diff lists. ?Those programs can also
>> be buggy, but again I'd prefer that Mailman not compromise on this issue
>> for their sake.
>
>I predict you will eventually lose on this.  That's not an argument
>for changing, of course. :-)

Possibly, but let's go down fighting. :)

>> The point being that messages that flow through Mailman will have that hash
>> in the message URLs in the Archived-At header and possibly in the decorated
>> footers. ?An archiver should certainly provide an interface to look up a
>> message by pure Message-ID or the hash. ?The hash is just a scheme to
>> regularize the message id and is a tiny fraction more user-friendly
>> (because of its limited alphabet and manageable, known-in-advance length).
>
>I would say that's actually quite significant, because the trash that
>I've observed in message-ids is varied, to be polite.  It will be nice
>to be able to avoid URL-escaping, RFC 2047 soft line breaks, and all
>the rest.

Exactly!

-Barry

From mdoshayan at gmail.com  Fri Mar 30 05:24:37 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Fri, 30 Mar 2012 08:54:37 +0530
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAL_0O196TmaOAZW3sU4xfMK1=Fp2bsY3o2AYX5ekWx3qVKhC2Q@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>
	<CAL_0O196TmaOAZW3sU4xfMK1=Fp2bsY3o2AYX5ekWx3qVKhC2Q@mail.gmail.com>
Message-ID: <CAKfaKcNbUnUg85KH2dydA8rHwvuU1xDjVmP5hqegZ14N5a-L_Q@mail.gmail.com>

On Fri, Mar 30, 2012 at 5:05 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> On Fri, Mar 30, 2012 at 3:55 AM, Shayan Md <mdoshayan at gmail.com> wrote:
>
> > Assuming that we have something like this(object-ID-addressable, If I am
> > not wrong, mailman3 made it possible but not yet implemented as it's part
> > of archiver), is it over ambitious to plan to implement indexer/searcher
> > for mailman3 and a REST API to use this searcher, extend client to use
> this
> > api,
> > and django search form along with this client api? All this independent
> of
> > archiver. Because the only part common with archiver is message retrieval
> > part,
> > If we implement whole searcher, and rest of the client code, later when
> > archiver is implemented message retrieval code can used in searcher. When
> > archiver is completely mature may we can even merge them together. Is it
> > possible? Or this plan has any 'non-sense' parts?
>
> Hi, Shayan.  It's not nonsense, but (1) how do you propose to test if
> you have no archives to run it on?  And (2) search and retrieval may
> do a *lot* of message access, for example if you want to do data
> mining (see Ana from Spain's thread).  In that case, you may find that
> maildir imposes too many stats, which are very expensive on some
> platforms (and not cheap on any that I know of) and mbox requires too
> large memory.  So for some purposes a summary/index/search engine may
> want an optimized message store.
>
Isn't it the purpose of index? I mean, when we search for something we
don't have stat all the messages, search the index return the best matching
message IDs. If you wish to see the message then retrieve it(may be through
archiver). Probably we can index messages through cron every night.

>
> Those may not be your purposes, of course, in which case a simple mbox
> accessor and a download of a couple of mboxes from any public Mailman
> list will give you test fodder.
>
> Testing itself is not really a matter of personal preference.
> Although Mailman is not a 100% test-driven shop, Mailman 3 already has
> a *lot* of tests and Barry would like to see any new modules covered,
> I'm sure.  Also, this area is fraught with pitfalls for the developer.
>  See this thread, for example:
> http://thread.gmane.org/gmane.comp.python.devel/131395/focus=131406.
> _______________________________________________
> 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/mdoshayan%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From stephen at xemacs.org  Fri Mar 30 07:18:45 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 14:18:45 +0900
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAKfaKcNbUnUg85KH2dydA8rHwvuU1xDjVmP5hqegZ14N5a-L_Q@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>
	<CAL_0O196TmaOAZW3sU4xfMK1=Fp2bsY3o2AYX5ekWx3qVKhC2Q@mail.gmail.com>
	<CAKfaKcNbUnUg85KH2dydA8rHwvuU1xDjVmP5hqegZ14N5a-L_Q@mail.gmail.com>
Message-ID: <CAL_0O183b-kZThC1jTRoCeDYBL+6NNS-Tqps8HD1y2jOg_hncA@mail.gmail.com>

On Fri, Mar 30, 2012 at 12:24 PM, Shayan Md <mdoshayan at gmail.com> wrote:
> On Fri, Mar 30, 2012 at 5:05 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

>> And (2) search and retrieval may
>> do a *lot* of message access, for example if you want to do data
>> mining (see Ana from Spain's thread).

> Isn't it the purpose of index?

Yes, of course, but possibly it's not good enough.  Yes, when you know
what "features" (eg, author)  you want to index.  Then you can use an
online algorithm, indexing messages as they come in.  However, many
data mining methods are adaptive, meaning that they discover features
of the corpus over time (eg, through "Bayesian" algorithms) and then
wish to go back and reindex or cross-reference previously examined
messages based on more accurate feature specifications.

As I say, if that's not your purpose, then you don't have to worry
about it.  But in some cases it will matter (eg, pretend you're
Google, not just a GSoC student!)

From pingou at pingoured.fr  Thu Mar 29 10:48:35 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Thu, 29 Mar 2012 10:48:35 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
Message-ID: <1333010915.20501.2.camel@ambre.pingoured.fr>

On Thu, 2012-03-29 at 10:49 +0900, Stephen J. Turnbull wrote:
>   Hyperkitty is the demo that
> a few people have been working on, including Toshio at the sprints,
> but there are others in play (eg, recent posts to this list).  Also,
> Hyperkitty is currently based on somewhat limited technology (the
> notmuch indexer).  I'm not sure it would be up to the demands of
> data-mining.  Of course, if Toshio says it is, listen to him, not me.
> :-) 

For the record, the current version of HyperKitty has moved from a
notmuch backend to a mongo database allowing a much more flexible data
storage scheme. This is the one you can see online at:
http://mm3test.fedoraproject.org/
The demo is getting more and more complete with month view, recent
activities, thread view, basic search functions and categories.
My only problem is that we seem to have some memory leaks at the
moment :-/

Pierre

From mdoshayan at gmail.com  Fri Mar 30 07:58:27 2012
From: mdoshayan at gmail.com (Shayan Md)
Date: Fri, 30 Mar 2012 11:28:27 +0530
Subject: [Mailman-Developers] Google Summer of Code: Integration of
	Search Code
In-Reply-To: <CAL_0O183b-kZThC1jTRoCeDYBL+6NNS-Tqps8HD1y2jOg_hncA@mail.gmail.com>
References: <CAKfaKcMF7YXPwByzg0GBeXtegQhbgB-5Y-fTeVi_kn-azFyenQ@mail.gmail.com>
	<20120326194107.GX11151@unaka.lan>
	<CAKfaKcPOHtFrdQs3XOLZ4-ALi5Br6kwkMtuikWEqfo97MqCyDQ@mail.gmail.com>
	<4F721331.60807@zone12.com>
	<CAL_0O1-cXLbxr=tCPGx4cvCbpy6bkRgeKZ1M4sX1twb1j-Ni3A@mail.gmail.com>
	<CAKfaKcNhqK4u4+=ApKx9uCXQe0Zd3m7yBL9tbmuUr+ggB75zQQ@mail.gmail.com>
	<CAL_0O196TmaOAZW3sU4xfMK1=Fp2bsY3o2AYX5ekWx3qVKhC2Q@mail.gmail.com>
	<CAKfaKcNbUnUg85KH2dydA8rHwvuU1xDjVmP5hqegZ14N5a-L_Q@mail.gmail.com>
	<CAL_0O183b-kZThC1jTRoCeDYBL+6NNS-Tqps8HD1y2jOg_hncA@mail.gmail.com>
Message-ID: <CAKfaKcPVgADGVJU95GK0G9m-8Y28wkYZzh5aq43QWRRH2JhS+Q@mail.gmail.com>

On Fri, Mar 30, 2012 at 10:48 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> On Fri, Mar 30, 2012 at 12:24 PM, Shayan Md <mdoshayan at gmail.com> wrote:
> > On Fri, Mar 30, 2012 at 5:05 AM, Stephen J. Turnbull <stephen at xemacs.org
> >wrote:
>
> >> And (2) search and retrieval may
> >> do a *lot* of message access, for example if you want to do data
> >> mining (see Ana from Spain's thread).
>
> > Isn't it the purpose of index?
>
> Yes, of course, but possibly it's not good enough.  Yes, when you know
> what "features" (eg, author)  you want to index.  Then you can use an
> online algorithm, indexing messages as they come in.  However, many
> data mining methods are adaptive, meaning that they discover features
> of the corpus over time (eg, through "Bayesian" algorithms) and then
> wish to go back and reindex or cross-reference previously examined
> messages based on more accurate feature specifications.
>
> As I say, if that's not your purpose, then you don't have to worry
> about it.  But in some cases it will matter (eg, pretend you're
> Google, not just a GSoC student!)
>

Okay then, can you please tell me how we can put this search code in best
use of mailman3? I have a proposal to write, I am getting unsure of things
day by day. Can you also tell me who is the mentor of this project?

> _______________________________________________
> 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/mdoshayan%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From stephen at xemacs.org  Fri Mar 30 08:46:36 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 30 Mar 2012 15:46:36 +0900
Subject: [Mailman-Developers] GSoC
In-Reply-To: <1333010915.20501.2.camel@ambre.pingoured.fr>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
	<1333010915.20501.2.camel@ambre.pingoured.fr>
Message-ID: <CAL_0O1-S_CJ7M-g9Ms1op1P_XRpu2AmskHT=q0pVN5hEJhWxrQ@mail.gmail.com>

On Thu, Mar 29, 2012 at 5:48 PM, Pierre-Yves Chibon <pingou at pingoured.fr> wrote:

> For the record, the current version of HyperKitty has moved from a
> notmuch backend to a mongo database allowing a much more flexible data
> storage scheme.

Good to know!  Is the source available?

From pingou at pingoured.fr  Thu Mar 29 21:49:09 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Thu, 29 Mar 2012 21:49:09 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
Message-ID: <1333050549.17059.6.camel@ambre.pingoured.fr>

On Thu, 2012-03-29 at 10:49 +0900, Stephen J. Turnbull wrote:
>   Hyperkitty is the demo that
> a few people have been working on, including Toshio at the sprints,
> but there are others in play (eg, recent posts to this list).  Also,
> Hyperkitty is currently based on somewhat limited technology (the
> notmuch indexer).  I'm not sure it would be up to the demands of
> data-mining.  Of course, if Toshio says it is, listen to him, not me.
> :-) 

For the record, the current version of HyperKitty has moved from a
notmuch backend to a mongo database allowing a much more flexible data
storage scheme. This is the one you can see online at:
http://mm3test.fedoraproject.org/
The demo is getting more and more complete with month view, recent
activities, thread view, basic search functions and categories.
My only problem is that we seem to have some memory leaks at the
moment :-/

Pierre


From pingou at pingoured.fr  Fri Mar 30 10:04:04 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Fri, 30 Mar 2012 10:04:04 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <1333050549.17059.6.camel@ambre.pingoured.fr>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
	<1333050549.17059.6.camel@ambre.pingoured.fr>
Message-ID: <1333094644.7863.2.camel@ambre.pingoured.fr>

On Thu, 2012-03-29 at 21:49 +0200, Pierre-Yves Chibon wrote:
> On Thu, 2012-03-29 at 10:49 +0900, Stephen J. Turnbull wrote:
> >   Hyperkitty is the demo that
> > a few people have been working on, including Toshio at the sprints,
> > but there are others in play (eg, recent posts to this list).  Also,
> > Hyperkitty is currently based on somewhat limited technology (the
> > notmuch indexer).  I'm not sure it would be up to the demands of
> > data-mining.  Of course, if Toshio says it is, listen to him, not me.
> > :-) 
> 
> For the record, the current version of HyperKitty has moved from a
> notmuch backend to a mongo database allowing a much more flexible data
> storage scheme. This is the one you can see online at:
> http://mm3test.fedoraproject.org/
> The demo is getting more and more complete with month view, recent
> activities, thread view, basic search functions and categories.
> My only problem is that we seem to have some memory leaks at the
> moment :-/

We might still get a third version of this email. As it seemed that they
were not reaching (which apparently they do now), I try to resend them.

Sorry for the noise.

Pierre

From pingou at pingoured.fr  Fri Mar 30 09:00:45 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Fri, 30 Mar 2012 09:00:45 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CAL_0O1-S_CJ7M-g9Ms1op1P_XRpu2AmskHT=q0pVN5hEJhWxrQ@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
	<1333010915.20501.2.camel@ambre.pingoured.fr>
	<CAL_0O1-S_CJ7M-g9Ms1op1P_XRpu2AmskHT=q0pVN5hEJhWxrQ@mail.gmail.com>
Message-ID: <1333090845.7863.1.camel@ambre.pingoured.fr>

On Fri, 2012-03-30 at 15:46 +0900, Stephen J. Turnbull wrote:
> On Thu, Mar 29, 2012 at 5:48 PM, Pierre-Yves Chibon
> <pingou at pingoured.fr> wrote:
> 
> > For the record, the current version of HyperKitty has moved from a
> > notmuch backend to a mongo database allowing a much more flexible 
> > data storage scheme.
> 
> Good to know!  Is the source available? 

Yes,
The main website: https://fedorahosted.org/hyperkitty/ 
To browse the sources: http://bzr.fedorahosted.org/bzr/hyperkitty/
(see the mongodb branch for the mongo backend, trunk is still on
notmuch)
and the demo is still at the same place:
http://mm3test.fedoraproject.org/

Pierre

From pingou at pingoured.fr  Fri Mar 30 07:26:54 2012
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Fri, 30 Mar 2012 07:26:54 +0200
Subject: [Mailman-Developers] GSoC
In-Reply-To: <CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
References: <CABDJ2UqfdnFRP_Gj_=v2GuYgkRGXkuu0Bgc8KHMV-+YONHPydg@mail.gmail.com>
	<4F736DBD.9000507@state-of-mind.de>
	<CAL_0O18PNFmiD_2CBA+5XVAna33s1SOkeT1BK9xtq7scVoUJ3w@mail.gmail.com>
Message-ID: <1333085214.17059.17.camel@ambre.pingoured.fr>

On Thu, 2012-03-29 at 10:49 +0900, Stephen J. Turnbull wrote:
>   Hyperkitty is the demo that
> a few people have been working on, including Toshio at the sprints,
> but there are others in play (eg, recent posts to this list).  Also,
> Hyperkitty is currently based on somewhat limited technology (the
> notmuch indexer).  I'm not sure it would be up to the demands of
> data-mining.  Of course, if Toshio says it is, listen to him, not me.
> :-) 

For the record, the current version of HyperKitty has moved from a
notmuch backend to a mongo database allowing a much more flexible data
storage scheme. This is the one you can see online at:
http://mm3test.fedoraproject.org/
The demo is getting more and more complete with month view, recent
activities, thread view, basic search functions and categories.
My only problem is that we seem to have some memory leaks at the
moment :-/

Pierre



From syst3m.w0rm at gmail.com  Sat Mar 31 20:22:26 2012
From: syst3m.w0rm at gmail.com (Aamir Khan)
Date: Sat, 31 Mar 2012 23:52:26 +0530
Subject: [Mailman-Developers] GSoC : HyperKitty project
Message-ID: <CAOb12VU16yyuB8SL91KJFFa7zr7iNZUJq7tLh-wkz+++EKxY7Q@mail.gmail.com>

Hi,

I am Aamir Khan, 3rd year computer science student. I am applying for GSoC
2012 Project 'Mailman3 HyperKitty archiver project'.

I have written a proposal for this project. The proposal can be found here (
http://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/syst3mw0rm/1
).

I would be glad if other developers have a look at it and give some
valuable suggestions or any changes. Any sort of improvements / suggestions
/ comments are welcome!

Thanks for your time :)



---
Aamir Khan
IRC Nick: syst3mw0rm