[Mailman-Developers] GSoC Mailman and Systers (was Re: GSoC)

2012-03-28 Thread Terri Oda 



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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] any interest in a new built-in web-archive? (i.e. pipermail replacement)

2012-03-28 Thread David Jeske 
On Mar 27, 2012 8:47 PM, "Barry Warsaw"  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?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1

2012-03-28 Thread Jeff Breidenbach 
> 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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] mailman / archive-ui / licensing questions

2012-03-28 Thread David Jeske 
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@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailm

Re: [Mailman-Developers] GSoC 2012

2012-03-28 Thread Barry Warsaw 
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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code

2012-03-28 Thread Barry Warsaw 
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


signature.asc
Description: PGP signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code

2012-03-28 Thread Barry Warsaw 
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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code

2012-03-28 Thread Barry Warsaw 
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/... 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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC

2012-03-28 Thread Stephen J. Turnbull 
On Thu, Mar 29, 2012 at 4:59 AM, Florian Fuchs  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.
:-)
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Google Summer of Code: Integration of Search Code

2012-03-28 Thread Bill Janssen 
Stephen J. Turnbull  wrote:

> On Wed, Mar 28, 2012 at 4:21 AM, Terri Oda  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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Odhiambo Washington 
On Wed, Mar 28, 2012 at 22:31, Florian Fuchs  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@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@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
>
> 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.
<>___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC

2012-03-28 Thread Florian Fuchs 
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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Florian Fuchs 
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@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@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

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.
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Odhiambo Washington 
On Wed, Mar 28, 2012 at 20:03, Stephen J. Turnbull wrote:

> On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington 
> 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.
<>___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [Bug 265831] Re: Autoreplies confirm subscription invitations

2012-03-28 Thread Barry Warsaw 
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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Stephen J. Turnbull 
On Thu, Mar 29, 2012 at 1:40 AM, Odhiambo Washington  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.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Odhiambo Washington 
On Wed, Mar 28, 2012 at 19:40, Odhiambo Washington wrote:

>
>
> On Wed, Mar 28, 2012 at 19:13, Florian Fuchs  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@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 
>> > 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@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@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.
<>___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Odhiambo Washington 
On Wed, Mar 28, 2012 at 19:13, Florian Fuchs  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@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 
> > 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@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: odhia...@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.
<>___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Florian Fuchs 
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@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 
> 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@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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1

2012-03-28 Thread Barry Warsaw 
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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1

2012-03-28 Thread Barry Warsaw 
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.]

where  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
>arch...@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



signature.asc
Description: PGP signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1

2012-03-28 Thread Odhiambo Washington 
On Mon, Mar 26, 2012 at 00:34, 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?
>
>

Hey Jeff and all,

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

[root@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 
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.
<>___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [Question #191915]: unsubscription from conversations in Mailman

2012-03-28 Thread Barry Warsaw 
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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9