Re: [Mailman-Developers] Mailman 3.1 beta coming soon

[Florian Fuchs]

On Sat, Dec 03, 2016 at 17:25:24PM -0800, Terri Oda wrote:

On 2016-12-03 12:22 PM, Florian Fuchs wrote:

I did some manual integration testing today
(core+mailmanclient+postorius) which looked fine so far. I didn't get
to test HyperKitty and the bundler though, so any help testing those
would be very much appreciated. I will have some more time tomorrow.


I tried to do some testing based on these wiki instructions last weekend
https://wiki.list.org/HyperKitty/DevelopmentSetupGuide

and hit a "[Errno 61] Connection refused" issue when attempting to log 
in to Postorius.  I suspect it might be an issue with the mac, since 
googling for the error (it's a django one) seems to find a lot of 
people on macs with problems, but I didn't manage to narrow it down 
more than that to make a useful bug report.


Do you have a traceback somewhere? If you're logging in for the first
time, it *might* have to do with allauth trying to verify your email
address by sending you an confirmation email (which probably fails if
you don't have smtp set up on your mac).

If that's the case, we should probably try to catch this condition and
display a useful error message instead of just letting it break.

Cheers
Florian

I did set up a new linux install on another machine to work on next, 
though, so I may have something else to say on that front tomorrow.


Terri


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman 3.1 beta coming soon

[Florian Fuchs]

On Fri, Dec 02, 2016 at 11:07:24AM -0500, Barry Warsaw wrote:

Hello Mailman 3 users and developers!

It's been a long slog but I think we are finally ready to begin the release
process for Mailman 3.1.  I am pretty happy about the state of the Core, and
Florian is going to do some more integration testing with HyperKitty and
Postorius.  We still have a few issues and a merge proposal or two to address,


I did some manual integration testing today
(core+mailmanclient+postorius) which looked fine so far. I didn't get
to test HyperKitty and the bundler though, so any help testing those
would be very much appreciated. I will have some more time tomorrow.

I did all of my testing locally, which has some limitations. So I
started setting up a more realistic environment on one of my dev
machines. But I'm not done yet. Will report back when I'm done... ;-)


but I am planning to spin a beta of Core this weekend to facilitate testing.


I think it's OK to put out a separate beta of the core, because the
version pulled from pypi will still be 3.0 if I'm not terribly mistaken.

For the real 3.1 we should probably do a coordinated release of all
components, once everything's tested a little more thoroughly.

Cheers
Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] New lists at lists.mailman3.org

[Florian Fuchs]

On 18. März 2016 13:51:43 MEZ, Odhiambo Washington  wrote:
>On 18 March 2016 at 15:26, Simon Hanna 
>wrote:
>
>> On 03/18/2016 10:25 AM, Odhiambo Washington wrote:
>> > I try to login to test2 using google and I get Server Error (500).
>> >
>> > I can't use persona and I don't wanna use Yahoo!
>> citing the previous mail:
>> > Note that the login page offers Persona, Google and Yahoo for
>login, but
>> > only Persona works
>>
>> Why can't you use persona? It's working for me
>>
>
>1. Because I don't have a persona and there is really no point for me
>getting one since it's headed for closure.
>2. I have google.

You can use your Gmail address to sign in with Persona. No additional account 
necessary.

Cheers,
Florian





___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] INTEREST IN IMPLEMENTING Message queue based email archiver

[Florian Fuchs]

On Tue, Mar 15, 2016 at 11:50:10AM -0500, Okusanya Damilola wrote:

Thanks for your reply. I am currently studying the existing
implementations mhonarc
and mailarchive (both in src/mailman/archiving) and also Hyperkitty.


Good!


Someone also mentioned in the thread that studying the GNU mailman
architecture in the "The Architecture of Open Source Applications" would be
helpful. Is that applicable to this scenario? I will come up with a draft
implementation on Thursday.


This article will give you a great introduction into the general architecture
of the Mailman core, so it will certainly benefit you to read it. However,
this particular project will probably require only minimal (if any) changes
to the core.

It's a good idea to code a simple draft to check out how the IArchiver
interface works. But at this point in the GSoC application phase it's also
very important to think about where you want to go with this project, like:
Which backend(s) to choose for a start, what possible use cases could be etc.

Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Gsoc Support for Message queue based email archiver

[Florian Fuchs]

On Sun, Mar 13, 2016 at 16:22:25PM +0530, Anirudh Dahiya wrote:

Hello
I am a computer scrience undergrad at IIIT-Hyderabad, India.

I was looking through the GSoC 2016 ideas and would like to know more about
the project "message queue based email archiver"


Great to hear you're interested in this project. I've just responded to
another question regarding this project that is equally relevant to you:

 http://www.mail-archive.com/mailman-developers%40python.org/msg16305.html


I have played with codebase of mailman and postorius for some time now and
am currently trying to understand how Hyperkitty works.
Also, as suggested to other students regarding this project, I have gone
through the chapter on mailman in the book The Architecture of Open Source
Applications, the pycon talk on mailman by Barry and have also gone through
relevant parts of the documentation.


Sounds good. If you're already reading through the HyperKitty source, you
might give special attention to its implementation of Mailman's IArchiver
interface, as well as the implementations for the mail-archive.com and
mhonarc archivers in the Mailman core projects.

Florian



Regards
Anirudh Dahiya
(spark on IRC)
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] INTEREST IN IMPLEMENTING Message queue based email archiver

[Florian Fuchs]

On Sat, Mar 12, 2016 at 01:34:34AM -0600, Okusanya Damilola wrote:

Sir,

My name is Okusanya Oluwadamilola. I am currently enrolled for my Masters
programme at Saint Cloud State University at St.Cloud Minnesota. I played
around with Apache ActiveMQ last semester and have some basic Python
skills. Could you shed some more light about the project? Thanks for your
prompt and favourable response.


The idea behind this project is to use Mailman's (Python-based) IArchiver
interface to add outgoing posts to a message queue (or pub/sub) system which
can be consumed by any number of applications, no matter if they're written
in Python or not -- asynchronously, even simultaneously. This would open up
Mailman to all kinds of use cases, maybe some of them beyond that of a
"traditional" mailing list.

One part of the project would be to choose and integrate a small number of
backends (ActiveMQ could be one of them, but I think both first-in-first out
as well as pub/sub are interesting concepts) to distribute list posts.

The other part is to come up with an interesting idea how this could be used
and maybe create an implementation of that too (depending on the
application's scope): Say, hooking it up to a static web page generator. Or
creating a websockets server based on this. (These are just spontaneous ideas
-- get creative!).

In order to prepare for this it makes sense to study Mailman's IArchiver
interface in the core (src/mailman/interfaces/archiver.py) and check out the
existing implementations: mhonarc and mailarchive (both in
src/mailman/archiving), but especially HyperKitty.

Florian



Sincerely,

Okusanya OIuwadamilola.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] CAPTCHA support

[Florian Fuchs]

On Sat, Mar 05, 2016 at 16:27:31PM +0530, Aditya Divekar wrote:

Hi!
I was looking around the mailman code, and could not find the functionality
for captcha in the mailing lists subscription pages.
I think it could be a good feature to implement in the upcoming versions,
and would like to know if its a good idea?
I also came across the thread -
http://permalink.gmane.org/gmane.mail.mailman.user/74167
and read about the previous discussion on it by some members.
Since captcha back then was easier to break, it might not have been a
profitable feature, according to the thread.
But with the new recaptcha, I would like to know if the stand is the same.


There are a number of alternatives to captchas to prevent spam. None of them
is perfect, but one I kind of like is the honeypot approach:

It's basically an empty and visually hidden input field that is ecpected to
be emptily submitted. Most spam bots will try to fill it with some text,
which is the warning flag that can be used to ignore those submits.

The big plus is that it won't require human users to take any extra action,
making it completely unobtrusive to *most* users.

The one major downside is that it might be confusing to users who use screen
readers and to whom this extra input is properly displayed, which might cause
some confusion. Of course, this can be solved somewhat by labelling the field
accordingly, something like "Are you human? Than keep this empty".

Also, I have no idea how sophisticated spam bots are becoming in detecting
honeypots, for instance by only trying to use "known" fields like "username",
"email address" and so forth.

Still, even if this is not a perfect solution, it might still be better than
the big usage impediment of captchas.

As a side-note, especially to those who are using screen readers: What is
your experience regarding the use of JavaScript in current screen readers? Is
this still mostly a no-go for web sites aiming to be accessible or has there
been some improvement?

Cheers,
Florian




Thanks

Aditya
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

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

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] python error when try to save a setting

[Florian Fuchs]

On Tue, May 05, 2015 at 09:53:03AM +0200, Thomas Stein wrote:

Hello.

When i try to save a setting

--schnipp--
Settings / Message Acceptance

Default action to take when a member posts to the list --- Accept


The list of acceptable aliases isn't handled properly. I am working on a fix.

As a work-around (if you don't need to define acceptable aliases), you can
empty the acceptable aliases form field before submitting the form. 


Florian




signature.asc
Description: Digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] Welcome to GSoC 2015

[Florian Fuchs]

Fellow friends of Mailman, dear students, 


welcome to GSoC 2015 (the Mailman edition)!

First of all: We were overwhelmed by the amount of interest in Mailman during 
this year's application phase. We got far more applications than expected, and 
in the process many bug fixes (and new reports) and merge proposals. Thanks to 
all the applicants who asked questions on IRC, posted thoughts and ideas to 
this mailings list and submitted an unexpected number of great proposals. You 
rock!

Google gave us 3 slots (which is a really good number, given we're in as a 
separate org for the first time in years). But having to pick 3 out of 25 left 
us with some really hard choices. So for those who couldn't get in this year: 
Please don't feel discouraged to keep contributing to Mailman or to try again 
next year!

But now, without further ado, let's welcome our three GSoC students:

Ankush Sharma - Mailman client written in JavaScript
Mentors: Florian Fuchs, Abhilash Raj

Bhavesh Goyal - A Dashboard for Admins/Owners/Moderators
Mentors: Abhilash Raj, Sneha Priscilla Makini

Pranjal Yadav - Dynamic Sublists
Mentors: Stephen Turnbull, Terri Oda

Congratulations to you all -- we are looking forward to working with you! Let's 
have a great summer!

Florian



signature.asc
Description: Digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman 3 discussion

[Florian Fuchs]

On Di, Apr 21, 2015 at 09:40:52 +0300, Danil Smirnov wrote:

2015-04-21 0:34 GMT+03:00 Florian Fuchs f...@florianfuchs.com:

OK, the problem was a file name conflict on the Python package index (due to
an erroneously omitted pre-release suffix while parsing the version string
of
a previous beta-release), which eventually led to pypi delivering the
previous release's tarball. I've associated a new file with the latest
release on pypi so the correct tarball gets installed.

Sorry for that...


Okay, but what is workaround right now?
I don't see any new revisions in the mailman-bundler...


The change is not directly reflected in mailman-bundler. But running
`buildout` again should install the newest version of mailman.client. 


Florian



signature.asc
Description: Digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman 3 discussion

[Florian Fuchs]

On Mon, Apr 20, 2015 at 22:36:14PM +0300, Danil Smirnov wrote:

2015-04-20 22:22 GMT+03:00 Florian Fuchs f...@florianfuchs.com:

That looks like incompatible versions of Postorius and mailman.client
 to me. The currently available ones on pypi and launchpad (released
on Friday) should be working. Did you download them before Friday
evening (EST) by any chance?


Nope. I've downloaded very last revision couple of hours ago.


OK, the problem was a file name conflict on the Python package index (due to
an erroneously omitted pre-release suffix while parsing the version string of
a previous beta-release), which eventually led to pypi delivering the
previous release's tarball. I've associated a new file with the latest
release on pypi so the correct tarball gets installed.

Sorry for that...

Florian



signature.asc
Description: Digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman 3 discussion

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 20.04.2015 um 20:13 schrieb Danil Smirnov:
 I would like to ask too.
 
 After successful fight with 'virtualenv' buggy version bug 
 (https://bugs.launchpad.net/mailman/+bug/1445764) I've proceeded to
 initial setup through the Postorius web inteface.
 
 I opened the link http://127.0.0.1:8000/mailman3 in the 'links' 
 browser and try to add new domain through 'Manage lists' -
 'Domains' - 'Create domain' form.
 
 When I submit the form, I get the error:
 
 --- [root@host ~]# links http://127.0.0.1:8000/mailman3
 
 
 TypeError at /mailman3/domains/new/ (p1 of 18)
 
 TypeError at /mailman3/domains/new/

That looks like incompatible versions of Postorius and mailman.client
 to me. The currently available ones on pypi and launchpad (released
on Friday) should be working. Did you download them before Friday
evening (EST) by any chance?

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVNVHyAAoJEEceGbPdavl74bwIAKOAkO6zAIkTbhFNY4P9VFF0
o3TkeFpf2VVdmiQihQczk7ToTprfnGvu5PFo5jX77AaFyF4gaEOaFSfQ6/wwomwL
nPb4XayVolceaa5oJbXmPE5XtVUJwVrUrIz9MXreoPDNS9QldUc1c95VVBPQSwQM
7vY1Bc/i2iMRONyTO2ZLWuvVXQwQrSKLlL4P2A1NR7eStE7z+9D17X8jE14Pq8sA
uv9Fxy8KMHilXxmGLPePZ6483a415vy9lNCqde6iXbLLk3Tj4FZRgCmBSbw+m+RB
Zgt8rJoqn/lLSpN9W/oKDZI4bn2svHK0gmotwspq8qGM+ZDWDJaVmiGNS3Dql/4=
=rko1
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Javascript Client for Mailman

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 25.03.2015 um 07:51 schrieb Ana Badescu:
 Hello,
 
 While writing my proposal I came across 2 important issues related
 to the Javascript Client for the Mailman project that have yet to
 be raised:
 
 1. What I initially had in mind, was to build a Mailman client in 
 Javascript that provides the same API and functionality that the
 current one in Python does. The Python client API can be fully
 mimicked using a number of design patterns even though Javascript
 doesn't offer properties capability for example. However, node.js
 modules tend to take advantage of Javascript's asynchronous nature
 and have adopted sort of a standard practice to achieve it: it's
 called error-first callbacks, and most if not all APIs enforce it.
 You can read about it here 
 http://thenodeway.io/posts/understanding-error-first-callbacks/ and
 here 
 https://docs.nodejitsu.com/articles/errors/what-are-the-error-conventi
ons

Another
 
*very* nice way to handle asynchronous behaviour in JS (and
one the avoids callback hell) is the Promises paradigm. Promises are a
native ES6 feature per-spec, but not all platforms support it. Node
doesn't, but there's a drop-in polyfill[1] and a number of other
libraries you could use.

 This boils down if we want to provide a client API that adopts the
 node.js conventions and works the same way most modules do or do we
 want to offer something almost similar to the current Python client
 API. There's a lot more to be said on this matter (for eg:
 callbacks being the reason why callback-hell exists) but I'd like
 to get your input first.

The JS client should be able to do the things mailman.client can do,
but that doesn't mean its internals need to be anything like
mailman.client's. *Some* similarity to the Python version would be
nice, but not to the extend that we do something in a way you normaly
wouldn't in JS. The intended audience are folks who use JS, so I'd
rather not have a client that runs on node but looks like Python. :-)

 2. I'd also like to make part of the project, a node.js application
 that uses the Mailman Javascript client and offers all the
 functionality Postorious does. Is that a good idea? This doesn't
 make the scope of the project too large or unattainable.

All the functionality that Postorious does sounds like your summer
is *a lot* longer than mine is. :-) I definitely don't see that.

What you could do though is add an *optional* task to your timeline,
building a *very small* and stripped down web ui proof of concept,
with only a small handful of features that you can use to demonstrate
how to integrate the client. But that shouldn't be worked on before
anything else has been finished.


Cheers,
Florian

[1] https://github.com/jakearchibald/es6-promise


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVEsTAAAoJEEceGbPdavl7Vi8H/0+oj9soM2oRDHBYpnPZo4OG
NSwobau3vKrmja/OU0lrXOwlYxfYo+WeQnmf17dlvJOk9zYqPCtSLT5emcV3gQjv
vWgzBFwG2sXY0MM/rvfSS+CUIzpNPI+kdhOXriQxhkylBu4aDl8XCiII1xmry7u6
5aFzMygFuV6ixyZRUwriB+qbqvxYdQ+eFkW+LyBvk4y0fkjTEK0/9fXnghkc8fuq
taYAbCnhpKZtO6hAsIgQoPPtuGDEqPq5VjjIU89JGeaRjxZ/LX/SOHh2thpgXhre
JD+3W5FdziCp3qFijeQCVuK/fErEF1nevC5/wTeeW9fY7/ZOT5GhYCDs4i6EjkM=
=3uJ7
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Small change to REST API for held subscription requests

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 22.03.2015 um 02:32 schrieb Barry Warsaw:
 I want to make some minor backward incompatible changes to the
 JSON representation for pending mailing lists requests, e.g.
 subscription holds. You'll see these for example in urls like:
 
 dump_json('http://localhost:9001/3.0/lists/a...@example.com/requests
')



 
entry 0:
 delivery_mode: regular display_name: Anne Person email: 
 a...@example.com http_etag: ... language: en request_id: ...
 type: subscription when: 2005-08-01T07:49:23
 
 The first change is that `type: subscription` requests will change
  their `address` key to `email` for consistency with other parts of
  the API.  Second, there will be no `password` key.
 
 Let me know if this is a problem, and I can copy `email` to
 `address` so that both would appear, and add a dummy `password`
 key.

As for the `password` key: It's recognized by mailman.client and
exposed within the mlist instance's `requests` property. But it's used
nowhere in postorius and I would be surprised if it's used anywhere in
hyperkitty (Aurélien...?). I guess it can go away.

As for the email/address keys: We can also just keep the `address` key
in mailman.client and let it use the same value as `email`. That way
we would still have a fallback but the REST API would stay clean and
wouldn't send any redundant information over the wire.

Can you notify me when your API changes are pushed to LP, so I can
update mailman.client accordingly? Just to keep the window as small as
possible where we have non-compatible states in the
mailman/mailman.client trunks. Especially during GSoC application
week...


Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVDyxKAAoJEEceGbPdavl7VicIAIvPKbwYfpAHDHBDNHjQALjZ
eTjz1KjaH/q9cyAQ1rmhttH1emiz5BukKOIvUTxeANc8ooscHXmUN+Prs1ahgebe
tSS7lKvc14kx9QW1HRvbQdnQpYcicNyTSZhTjeD/+RDIaUE+MWaRRxGbcOkHXCHT
OrmXeBSOAYGHPrNsExUcIBwRz8IdjFajQ8FIYS/GddsFeotUBJfQxQ7xdkDJMYkB
6iuPtuWwEKXvbxZLMgPtpCpuxYxOeS+cfQarXCdXLmrwruYNDPK0T16TQOa+QC+o
/3oNR5aKOTWmy3Dg+Jf2+CJ2eKmQ/NPqvWotXkl2h5CdwWu+TB8RZBTA3XQ91Z4=
=v1VH
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GitHub/development tools integration project Gsoc'15

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 18.03.2015 um 16:29 schrieb Prabhanshu Abhishek:
 2)the gsoc idea page says that it is necessary to fix at least one
 bug, but i have not been able to find some bug that is beginner
 friendly and related to my project, can you give me some bug to
 work on that will help me on my project.

It doesn't have to be related to that particular project idea. If you
don't find a bug in our bug trackers, it can be also be a small
feature or improvement you come up with yourself. It could also be a
test case for a piece of code not yet covered by a test (if the test
case is not all too obvious).

 3)some other necessary things that i should work upon before
 submitting my proposal. 4)and lastly who will be my mentor, can you
 tell me?

We generally don't know yet who's going to mentor which project.


Cheers
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVCzhaAAoJEEceGbPdavl7KSEH/igYUM4wUq3+y0prO2pQ9gyl
vb1L1kVlwmoOCFnmOfStRPfH0AAhrvzM+MYpyzJtHQaJZUFTg+Qs0hWb0u7wvU96
5Iy6Zev4UAvzzJ6sVE3UiAovs6IjurQsu4qwzsgYKPpH65gYPBEtb/qSh8UF9vvm
Vw9UgfSBzuPM9R+SsxLpliB2oYXDj1/RqpIdhtnAC9xORnCu3D5xpyHS6Ge8ZUAV
qLPJiaSIC/Js/xumiPl1Uq+xLgwnlO1+FsJrkwF6rgV79x5Of80gI3ysuEWhwyrn
/AbScAjxCBirW2qV5m4FFwMJ0QSztc3OnKEOx61rZ8dZgANFlMn8AjVSiqY2RuI=
=AdNV
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSOC - Dashboard for Admins/Owners/Moderators

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 13.03.2015 um 12:20 schrieb Yash Mehrotra:
 5. We also also give each list its individual page, so the admin
 can do list specific functions like, say change settings , ban user
 etc.

That's probably out of the scope of this project. The lists already
have moderation/settings pages. No need to redo this. If something can
be improved on that end, it's probably part of a separate effort.

 *Bug Fixes* I have also submitted a patch for a bug in postorius (
 waiting for some to look at it) and am also working on a bug in
 Mailman core.

I can't see a merge proposal from you for postorius, could you check
if your bugfix branch is proposed for merging? Oh, and don't forget to
add a link to the MP to your application.

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVBxbNAAoJEEceGbPdavl7bP0H/jY1J05viF+FqaL6GhtJUAwT
/yI8nmFKExOiuieG7M0+TWkVJZ82ztzhHyV6ekQE9gzRhPD6yLbGzRk28USpKU1h
itP87X0oijbw2zA/zsCpkeN0a81Zkr4ai+eINH1nDGgExdOA+Jr30mrbc/FwLREF
h73Pi9KBrSSVu9p38RwKI077NSWaeN3qkAlNc2Map6cVNx8W+5UqP/FNCNNSAWnD
VY+c+hoPwvPtpvUfVWjTBZXiaLZFTRx98t42Pav6ZxvUoEmqeyUP7KIDgeAlOwaE
ScQu/7bJI7Vvt5ggbFuYExTvZHMOo3JOuP/AbyiTHKiZANZmevQ7R1Ip/+BA0Jw=
=9xlG
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Gsoc'15

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 16.03.2015 um 14:50 schrieb Sagar Ghai:
 Hi, I would be interested in contributing to one of the projects
 named: anonymous lists as part of GSOC'15. I am a second year
 undergraduate student at IIT-Mandi, India. Can someone let me know
 how to move forward with this.

Hi Sagar,

there has already been quite a bit of discussion about this project on
this list. You could start by checking the archives and read what has
been discussed so far. I'm sure this will get you started pretty well.

Florian




 ___ Mailman-Developers
 mailing list Mailman-Developers@python.org 
 https://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:
 https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

  Security Policy: http://wiki.list.org/x/QIA9
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVBw4FAAoJEEceGbPdavl7GcIH+gMFTEP7S0fgxfEE/NNqGnKG
StkVGbL+vwmtzJsEZCv6Tse0q/8H3sQA9ZMBZaUEMgLAyrTJsQLtwNoMOIyVFNn2
u3IWyUp5QXs5qM0FAMw5Ec65eodYtc9PrpSGioNc97S/E6OKZmvKf9q45PC27boF
/SD7q7ZGHglVGTcXAJqs+jrJEFUYsvEr1GY7hrnCAnM3/fCpbL1SRVGALGfKsVL8
tWUknjsCFmmDPy5Rn8kO6lqghmHjkClXQWdD9Zjqnu+OXoT5Cf4bvYiwjwdX2WVo
9M2W/cXwNT+IF7VADVF6Iv14Y2jGTEdpsBqrPKeMX/n8NlxIELHkRogU+CmY68U=
=5/hs
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSOC - Dashboard for Admins/Owners/Moderators

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 16.03.2015 um 03:04 schrieb Stephen J. Turnbull:
 Yash Mehrotra writes:
 
 *My Ideas - * 1. One issue currently as mentioned is owners of
 multiple lists have to go through all the pages for changes. I
 think we should show all the mailing list's
 requests,subscriptions etc. all in one page.
 
 This isn't a dashboard-level issue; this should be a facility at
 the core level -- the core knows which lists the user is
 responsible for, and what the pending tasks are for each.  Are you
 sure Mailman 3 + Postorius doesn't have this capability already?

Sure, implenting such a user-based lookup of all roles and
action-items in the core-API would facilitate things on the UI side.
Currently this would involve several different HTTP calls to collect
the data.

But I think this is an implementation detail (and ideally possible
solutions for this are part of any application for this project). To
me the most important feature of the dashboard is exactly this: A
single spot to show me where action from my side is required.

 2. The new list features should be opened from a different tab as
 a list admin doesnt do this every day.
 
 *The primary focus should be - to make it easy for an admin to do
 his daily activities.*
 
 I agree with the general statement, but are the new list
 operations really a problem if displayed on the main dashboard?
 
 3. So, the index page will contain stuff mentioned on point 1,
 and the there will be different pages for other stuff like -
 create/delete list, view statistics ( see next point)
 
 My experience with a non-web-based moderation system is that most 
 moderation/subscription requests can be judged from a one-line 
 display, and for more complex operations (eg, banning an
 apparently abusive would-be subscriber) use Web 2.0 tech like
 Javascript popup menus.  Of course they have to degrade gracefully
 if JS is disabled, and even if CSS is disabled.  But the main
 interface probably can include list creation/deletion and a few
 interesting stats.

That's what we currently have on the list-specific message moderation
pages in postorius: A single row for each message, details
(body/headers) in a model window if needed. IMO this could look
similar on the dashboard.

 6. One more cool feature would be to color code different types
 of things for visual ease. Eg. Subscription requests can be color
 A. Held messages can be color B. and so on. This will not only
 help the administrator but also would visually good to look at.
 
 Maybe.  On the other hand, maybe users will prefer to have the 
 tasks grouped (a group for subscription requests, a group for 
 moderation, a group for admin-initiated actions like list creation
 if permitted, etc).  Maybe color coding will look nice, but IMHO
 it's unlikely to be a big efficiency enhancement compared to
 grouping.

I think you need to a bit careful here. Different colors might make it
easier to distinguish between types of action items, but they will
most likely also introduce an implicit prioritization. But IMO the
priority of different types of action items can vary a lot depending
on lists' characteristics. Also, every admin might have a personal
idea of what's important and what's not.


Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVBxSgAAoJEEceGbPdavl7QwUIAKL/vHVfznp2mjzeKjssTZRq
1T5gLfqP1qRHUNO58bBX9b1jyZYqMCea6lXL3Zt6x2pEKka7tiIr84cysBXhcJtA
OfB7oaUujpjExKFlPrTMFwwSyj+Gp4R213wloKtM78jcTE0OLas6oZt4dnywiec0
AglOyDqqfkK4kyjkNeLc9wG8cvrtu5/QRAxWKVtvjir9UH38CYT0TFzXM9TEOuY/
oegEMj2+082eVe1hDHm3jjRQ7Qg4qGY26QnFonS5asdVZaZopX34+wxfRNpKMY9r
eZ9Ef/L9gnMfs6ddg5Lty4+43PyQTlafj61NWkHJqzvUAG0EMkyUSQs1mxNJWfE=
=1zw2
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSOC: Shared Bookmarking

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 04.03.2015 um 14:48 schrieb Vidit Bhargava:
 Hello everyone, I am a student of Computer Science and Engineering
 in National Institute of Technology Karnataka, India. I am
 proficient in Python and C++ and dabbled with JavaScript and HTML I
 would like to work on the shared bookmarking toolkit. How do I go
 about it?

As it says on the wiki page, the project description is just a
starting point: Parse links from posts and put them somewhere. So the
first thing needed is a good idea what exactly could be done with
those links. Just put them in a file? Publish them somewhere else,
e.g. a bookmarking service? Display them on a web page? If so, who is
allowed to see it? Should the links be followed/analyzed to get more
information?

As for the technical part: Obviously the starting point for this is
the message itself, but only if it's ready to be submitted (not
moderated or else). I guess one can think of that project as a very
specialized archiver. Hence, the first thing I'd make myself familiar
with is Mailman's IArchiver interface.

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU9zDtAAoJEEceGbPdavl7YjIH/jVtp/qXMiBBNEmD4MMg22Ho
xPc6dWDJZf+ShtCoO45UCebzc1YzN8TBV/YRCKZrRnJYxKmXzr/lGgkMlpEuYyWh
mpeIQE/0rPIyw6aVbH3LqovQeeUR4vkI+8q+YM4c8H4xfm1rq22HlsR7Iy3EcbR1
0/AOQR10q69Kace9S3rf6CUkXClzR9pdYM4sGtaHuHRUF/PJt5jSYQH2FZ4i4ZRD
yex3gSykTEuHFitNBXYJrIY3+CvGSVciefjfwQihXRJH4tFRtQ9w3+UpSk6PT6Hg
GllZJz36ErtDGyNzrYf0cKmQ5hXwxFAJzv3umDEI1vNBElxB3xBT/bjlBZe/m0c=
=LuMQ
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Bug in postorius, client not defined after shell invokation

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 04.03.2015 um 16:25 schrieb Ankush Sharma:
 Hello everyone,
 
 I started going through the postorius docs and found an issue
 while following this 
 http://postorius.readthedocs.org/en/latest/development.html#accessing-the-mailman-api

 
.
 
 The *client *is not defined after the shell invokation by doing
 *python manage.py mmclient*. The issue is because the *client *is
 not present in the *globals() *dictionary when it was used to
 invoke the interpreter. I have filed a bug regarding this issue: 
 https://bugs.launchpad.net/postorius/+bug/1428169 . The issue can
 be solved by putting *client *in the scope i.e add *client *to the
 *globals() *dictionary. I have discussed the bug with people on irc
 and they also faced the same behavior. I have patched it and will
 send a pull request shortly.
 
 Any views regarding this will be helpful.

Thanks for pointing that out. I have to admit I totally forgot about
this particular manage.py command, since it's more or less just a
shortcut to create a mailman.client instance using the given Django
settings. So it's nice to see someone actually read the documentation
in full and gave it a test! :-)

Let me have a look at the merge proposal. I'll add further comments
there if necessary...

Thanks!

Florian


 
 Thanks,
 
 Ankush Sharma github.com/black-perl 
 ___ Mailman-Developers
 mailing list Mailman-Developers@python.org 
 https://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:
 https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs.com

  Security Policy: http://wiki.list.org/x/QIA9
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU9zu0AAoJEEceGbPdavl72HUH/RqFw0c2cvB7NobDnGBbBahY
eoXX9flHeEczcxmUA7QdY8a0igyy7Y15l1oZHZATDbZIumQ7UoLqwvn6IyWmazUB
lUyFqT4mWQBWukjcyu4RODnlk5CDQxX0kTHSqY4ltNX+AF+aMht5Jv2ruaNI3zZS
6/rRUzY82nGDZThow4RnfZMaaAftyEgAnntYuJt2/UPeUTRRsHF6k0oFsORnEZk0
/sW4c9F4OfdmafjndRBcyAWIgxqhMJnEQcXqkm0L1oOjSI35APa/BmjdXzJXEQyt
suXYZDHCcTHn3ssRiOpvdTK0ZzJAwVZaDxkbiqt2MKbwWvk6aMx0Cj5aLo9e/G8=
=A42d
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] GSoC 2015: We're in...

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

just a quick FYI: Mailman has been accepted into GSoC 2015. \o/ Thanks
to everyone who contributed ideas and/or helped with wiki gardening!

I'll follow up with a road map for the coming weeks tomorrow.

To everyone who has volunteered to mentor: It would be great if you
could refresh your google-melange.com profiles now and start a
connection with GNU Mailman.

Here's to a great summer!

Cheers,
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU9NeaAAoJEEceGbPdavl7n6MIAKdjBP3GNjRH4WTFtf0ZK7ZL
1Dv9Tkwbf4KkR8tERuE+h2sIycKj0CLt1FDF7buZqre+RyeYOBjjoQ88m9yDQsSP
YLcv9GVmeCk+uAfWZgvkUukyVWn5qeFaGY9iPMcoHJycuB8Hosx4gUgHIFEagujq
6NLJmnCT+maSaOTG2/eFj/FI8itYeQIcxpi5Yb+pgTJtsm+CSY0CTiYGCbG/QisK
JobDIwUBuiLeXb4IUJKERSxtVMhQOy616/4kqOubS4e7rOxXWJLEX3yrUqM3/9vO
5ZK25Mcwmcp+Y00QfBHbeF7lx0AS4dUeEIgO3Sv2Pxb0qKgfKWayPNtI4n+MeWU=
=zT65
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 20.02.2015 um 06:46 schrieb Terri Oda:
 Thanks all!  I've put up stuff for the ideas I could describe well 
 enough off the top of my head.

Thank you Terri!

 Also, mentors, I've listed a few likely key people beside each
 project idea, but some of them are just a generic anyone can help
 with this -- if any of these particularly interests you, please
 put your name down. Google prefers we have actual names listed when
 we can (I'm not entirely sure why, as this hasn't proven to be
 helpful, but we can always change the names after the page is
 reviewed.)
 
 Applications are due 1900 UTC Friday, so around 13h from now!

I completed the application yesterday and was planning to do a little
more wiki-gardening today.

So let's keep our fingers crossed. Who knows, maybe we get bonus
points for persistence. ;-)

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU5w1BAAoJEEceGbPdavl78HAIAJ9Rj4K+L56TCn6iQd/rjSXC
KFpDXcwAQLITr4QRDYs8EAIHDYwp4X/i6ZyZBqyvtSodoeRKPzl6fDjTR+OnXCes
BIKw72/zvwMqZLP3U2BY8DosUbWpYTy6G70o3+XoKnvXivIX5hTp50A8L+BbQzfU
Rg+0uQ10DN6bJi8/yr5wXgK9qQv2aDoTGjriKhOvln6uT6agtnvFXA6JqiUoF1Es
1eqfdbO9bCl0SJ6HFwTkADwaG0psgaPQPWkKMaQQUB3INku09Duy1OEXuiWk+ceT
DPd3iEuCJZ5uSNgZ8Gt1InZtW1T0ZJtw1UxZ/kQm7wJoSKUyGhsDOfZr4BOyKic=
=cXki
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] installation problems blocking a new developer

[Florian Fuchs]

Am 20.01.2015 um 17:38 schrieb Sumana Harihareswara:
 Hi all! Thank you for your IRC help and for merging several of my
 patches. :)

Thanks for your contributions!

 https://bugs.launchpad.net/mailman.client/+bug/1411653
 Installation fails because of bdist_egg

That should be fixed as of 15 minutes ago. A fresh bzr checkout from
mailman.client now has support for Python3 and is installable inside the
same virtualenv as the mailman (core) package. (Thanks again, Barry...)

*But*: Installing it into a py3 venv means it will *not* work (yet) with
Postorius or Hyperkitty, since both apps are still running on Py2 only.
mailman.client communicates with the Mailman core only via HTTP, so they
don't have to be version compatible. Postorius and HK on the other hand
import mailmanclient directly, so they do need to live in the same venv.

So in order to get a dev environment for the whole suite running, the
best solution (for now) is to:

- install mailman into a py3 venv and run it from there
- install mailman.client, Postorius and/or Hyperkitty into a py2 venv

Hope that helps.

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Python 3

[Florian Fuchs]

Am 06.01.2015 um 13:48 schrieb Barry Warsaw:
 On Jan 06, 2015, at 01:37 PM, Aurelien Bompard wrote:
 
 I must also consider how much work it would be to just port HyperKitty 
 KittyStore to Python3.  All things considered, it may very well be faster and
 more reliable.
 
 Of course, I encourage any porting to Python 3 just on principle :) and
 certainly if I can help, let me know.  But you may still want to consider a
 more distributed communication protocol between core and HK.  What if a site
 wanted to run them on different VMs for example?

Another thing we shouldn't forget is that Hyperkitty or Postorius might
not be the only apps living in a Django project. Some people might
choose to integrate them into their long-running Django sites, with lots
of Py2-app dependencies.

Of course it would be easier for us to just port our apps to Py3. But as
far as I remember integratability was the main argument in favor of
keeping our Django apps bilingual when we discussed the topic at Pycon
last year. But then, hey, one *could* also argue we ignore these issues
in order to make a point.


Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] MM3 REST API testing [was: Python 3]

[Florian Fuchs]

Am 06.01.2015 um 04:24 schrieb Barry Warsaw:
 On Jan 01, 2015, at 11:40 PM, Barry Warsaw wrote:
 
 I'm playing with a solution that involves the use of the 'vcr' package
 
 So this branch is now ready for review.
 
 https://code.launchpad.net/~barry/mailman.client/bilingual/+merge/245537
 
 I even added documentation on how to run the test to record the yaml file
 containing the HTTP traffic.  There are tox rules for doing both the
 recording, and for running the test suite with the recorded traffic against
 both Python 2 and Python 3.  I've only tested 2.7 and 3.4 since I don't
 currently have good builds of 2.6, 3.2, or 3.3, but the tox.ini file should
 support those.
 
 There are now no imports of any `mailman` modules.  I did have to add a new
 top-level `queues` resource to the REST API which will allow you to inject
 messages, query, and delete messages from the various queues.  I thought this
 was a pretty handy feature anyway, and it was easy to add, so that's now in
 the Mailman 3 trunk.  Which btw, as you might notice, I did go ahead and merge
 the py3 branch.  I think with this mailman.client approach and a REST-based HK
 IArchiver implementation (TBD), it was safe enough to do, and I didn't want to
 have to continue to implement new features in both branches (e.g. the queues
 resource).
 
 Please have a look and let me know what you think.

I haven't had the time to look at it today. But will definitely do it
tomorrow. Thanks a lot!

Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] MM3 REST API testing [was: Python 3]

[Florian Fuchs]

Am 02.01.2015 um 05:40 schrieb Barry Warsaw:
 On Dec 27, 2014, at 01:16 PM, Florian Fuchs wrote:
 
 So far we haven't found a perfect solution for testing packages that
 rely heavily on the MM3 REST API. As far as mailman.client, Postorius
 and HK are concerned, testing without *some* core integration doesn't
 make too much sense IMO, because any changes in the API would go unnoticed.
 
 I'm playing with a solution that involves the use of the 'vcr' package, which
 as its name implies (well, at least for us, um, mature programmers ;) is a
 facility to record and replay HTTP traffic.  It's compatible with both Python
 2 and 3 and is available on the Cheeseshop.

I took a quick look at vcr and it really looks promising. Although
apparently it doesn't support VHS, which is very sad. But we can still
use it for testing I guess... :-)

 So the basic idea is to set up an MM3 installation (`tox --notest -r`
 suffices), then start up its REST server with a fresh mailman.db, and run the
 test suite against it.   This will capture the traffic in a yaml file, which
 we could ship with mailman.client.
 
 Then to run the test suite, you'd use vcr in replay mode against the captured
 yaml file.  Any time the API changes, you'd have to re-record the traffic
 against a fresh database.

That sounds fantastic! Do you think it might make sense to ship the
traffic dump with mailman instead of mailman.client (and work the
recording into the test suite somehow)? That way there would only be a
single file to observe for changes in the REST API. Sure, a change in
the yaml file  doesn't necessarily mean a change in the API (might as
well be just an additional test case or different test data). But still,
if the yaml file stays the same between commits, that would be a nice
guarantee that the API stayed stable.

 I have a branch that's working in this direction and it's promising, but I've
 also had to rewrite the testing infrastructure for mailman.client, and make
 some other changes.  It also points out what I think are some bugs in Mailman
 core, so I'm working those out on my py3 branch in parallel.
 
 It's not yet ready for review, but if you want to keep an eye on things, look
 here:  lp:~barry/mailman.client/bilingual
 
 Feel free to provide feedback on the approach, or the changes so far, but I
 will submit a merge proposal when/if it's ready to go.

Thanks for starting the port, Barry. Looking forward to seeing that
merge proposal (although I don't expect I'll have a too much to add... ;-).

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Python 3

[Florian Fuchs]

Am 29.12.2014 um 00:26 schrieb Barry Warsaw:
 On Dec 28, 2014, at 01:51 PM, Aurelien Bompard wrote:
 
 As I mentioned, I think LMTP *could* work, but REST (inside HK) could
 work too.  Aurelien, what do you think?

 I'd go with REST, it seems more flexible and we already have nice libraries
 for it.
 
 REST will be very nice, and I think with something like Falcon, pretty easy to
 implement.  You probably don't need the object-based (i.e. restish-like)
 traversal stuff, but if so, I'd be happy to split that out into a separately
 library that HK could use (and keep it bilingual).  Keep it simple, but think
 through the resource tree and leave open some opportunities for expanding the
 API later, both for use by MM3 and perhaps other scripting applications.

Are you planning to implement that in a way similar to the IArchiver
interface? Like, say, having a REST-based equivalent for each of the
IArchiver's `list_url`, `permalink` and `archive_message` methods?

I think it would be nice if it worked more or less the same as the an
IArchiver class, not only on the implementation side but also as far as
the configuration is concerned. Although allowing multiple, potentially
slow-answering, REST-based archivers could be a trap performance-wise
(if those requests are not made concurrently).

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] new wiki, get-togethers, and 3.0 blockers

[Florian Fuchs]

Am 02.01.2015 um 06:14 schrieb Sumana Harihareswara:
 * I'd love to get to hack with some of you in person. Are any of you
 planning on going to the PyCon sprints in Montreal April 13-16?

Yup.

 * I saw in the
 https://mail.python.org/pipermail/mailman-developers/2014-November/024056.html
 conversation that I should be looking at
 https://bugs.launchpad.net/postorius/+bugs?field.tag=mailman3-suite-blocker
 for Mailman 3 blockers. It looks like there are 13 blocker bugs left; is
 that still right?

Some of them already have patches attached to them and just haven't been
merged yet, and a few others are already in progress. So there are
currently 5 bugs with no one assigned to it:

https://bugs.launchpad.net/postorius/+bug/987100
https://bugs.launchpad.net/postorius/+bug/1062963
https://bugs.launchpad.net/postorius/+bug/1004049
https://bugs.launchpad.net/postorius/+bug/1006356
https://bugs.launchpad.net/postorius/+bug/1201150

Would be great if any of these would spark your interest! :-)

Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Python 3

[Florian Fuchs]

Am 29.12.2014 um 00:27 schrieb Barry Warsaw:
 On Dec 27, 2014, at 08:41 AM, Florian Fuchs wrote:
 
 How about a third option, a generic pub/sub or event archiver,
 implemented in py3? It would meet all the above criteria (archivers on other
 systems, no dependency on py3 -- or Python for that matter).

 We could start supporting one backend (zeromq for instance) and maybe
 add more later.
 
 This would be pretty cool.  Would you be interested in writing an IArchiver
 implementation for that?

Sure. I don't know how much interest there is out there in something
like this. But I think I like the idea enough to just do it anyway. :-)


Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] MM3 REST API testing [was: Python 3]

[Florian Fuchs]

Am 26.12.2014 um 16:38 schrieb Aurelien Bompard:
 And mailman.client must be ported too, since it does import stuff from
 mailman for testing purposes. I think Postorious is safe, but that must be
 verified (I believe it imports the testing framework from mailman.client
 and thus must be ported too).

I think, this is worth another thread.

So far we haven't found a perfect solution for testing packages that
rely heavily on the MM3 REST API. As far as mailman.client, Postorius
and HK are concerned, testing without *some* core integration doesn't
make too much sense IMO, because any changes in the API would go unnoticed.

The first solution for that was to start the core (out of process) with
a temporary configuration and on a different port before running the
tests and tearing it down afterwards. That way mailman.client/Postorius
would be tested with a real MM core underneath it. Compatibility with
the API was guaranteed, but it was painfully slow and also a little
unstable. It's not fun when every typo is punished with a 10 or 20s penalty!

That's why I was extremely happy when Aurélien came up with a much
better idea a while ago. His solution made use of the webtest package,
which made it possible to test the MM3 API wsgi app without the HTTP
overhead or the need to start/stop the main MM process. Much faster,
more stable, a real delight compared to the situation we had before.

Unfortunately, this now means direct from mailman imports which will
break with incompatible Python versions. Too bad, we didn't think about
this (I, for one, was aware of the fact that Barry plans to do a
monolingual port at some point in the future. So I could have thought
about that earlier. :-/ meh...).

Of course, in order to make our tests work with a py3 MM core, we could
go back to the slow and no-fun way of testing that we had before. But
maybe there's better way...

Any ideas?

Cheers
Flo

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Python 3

[Florian Fuchs]

Am 27.12.2014 um 05:18 schrieb Barry Warsaw:
 I tend to agree that a good design for any archiver is to be able to accept
 messages over an IPC channel.  A site may for example want to run the core on
 one system and HK on another system (e.g. separate VMs perhaps).  This would
 only really be possible if the core can feed HK messages over a configurable
 IPC.  As I mentioned, I think LMTP *could* work, but REST (inside HK) could
 work too.  Aurelien, what do you think?

How about a third option, a generic pub/sub or event archiver,
implemented in py3? It would meet all the above criteria (archivers on
other systems, no dependency on py3 -- or Python for that matter).

We could start supporting one backend (zeromq for instance) and maybe
add more later.


Flo
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Error installing mailman.client due to Aurélien

[Florian Fuchs]

Am 12.12.2014 um 00:00 schrieb Aurelien Bompard:
 At first I thought I had introduced a regression but it's actually
 just my name :-)
 Don't blame me, I didn't choose it!

That's a great example why French accents are great: First, in French
you always know how a word is pronounced. And second, in Python they
shame you into correctly decoding/encoding your I/O. :-)

 (Florian, can you fix that? And by the way my last name is Bompard,
 without the A)

A fix is in the trunk.

And, argh!, sorry I used your IRC nick as your last name! ;-)

Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] mailman-bundler-3.0b2 Login methods

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 11/08/2014 07:50 PM, Vijay Tico wrote:
 Yes it reloaded to '/archives/' correctly. But the new page seems
 NOT logged in. The Login button is still there, and the
 administrative options don't appear.

mailman-bundler redirects to the '/archives/' index page (hyperkitty)
by default after login, but that can be changed[1]. The admin options
can be found under '/mailman3/'. What happens if you access that URL?
Can you see the admin options and -- hopefully -- a 'logout' link?

Anyway, even if that works, it's still strange that you see the login
button in the archives header after the persona dance is done...

Also, we should definitely make it easier to hop from the archives to
the admin pages and vice versa.

Florian


[1] Change the LOGIN_REDIRECT_URL to 'mailman3' in
mailman_web/development.py or mailman_web/production.py if you want
the login to redirect to the admin pages (postorius).

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUX8noAAoJEEceGbPdavl7xL0H+gOwCHtgk65DUYmhOJKLIR3y
hOUW3UHc8BJhzCBmCRunz7pLCC1LQWn6q5k22PHiCGavz9zwFW7E2mlkXr+tPE22
pBbtEP/62DkZgGFAzekRoP0JyHvqXSoae29kwX23ZEBTv6/+bvLy/voOEn+e2EUo
44xSS0LOKvsLjOp4imtSXtvFN6hir7iSlhN9ki5Mrtm30tg/1F/KIYTMl0tkExui
SPcun+50+Z8KLtxOzah99MbOnNSYC7ViV5ROiThlQkPIbYR4QsqxagAHOQ8k3a8B
6Dz+sS65HB2IxztidbEjR0FOFPXW+wBxBIcGKtucB5+8fxdBQ4s+CpFrAlQP8hs=
=OXnz
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] mailman-bundler-3.0b2 Login methods

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Vijay,

On 11/07/2014 04:03 AM, Vijay Tico wrote:
 I can't even get persona working. After login with persona the
 system just behaves like it has not logged it. Please help!

A couple of questions to get a little closer to what exactly went wrong:

Does After login with persona mean, that the persona login process
itself (new browser window/tab) went OK and without any errors?

Did the new browser window/tab close itself after you completed the
persona login? Did you notice any errors (in the browser console for
instance) during the process?

Did the mailman login page reload after the persona window/tab was
closed, and if so, did it redirect you correctly to the '/archives/' url?

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUXkxfAAoJEEceGbPdavl7sewIAKCb7gDhLvvFGdgIczr6gvC6
2m44plaI8V6tNq0pUPDLqYJHBInsGRxNpyKtsMjlYXF3/cW97PHfm8l5Ep4v5UKJ
sQFbV2/Rp2thSWt0dN56QaOme1zqAUMMigrxBbKkxCVvfooGT4ciO1IotHrxkAPk
x1c0d6pWckMhkLNz+KxwBVPhLcmV3uWb/W1f160bNNXn0V65/KPKweiAQfdmVcBV
b2/+Cqulkfoe7hTY3SLrEpzlGhdouVHS8OiVR2jnrYK1XBOVtN+eNqQUVtm27UGv
YUExS8zhQHHepEreXanZPG4pQPk9NBC7QYC8Ih7SI0ndPct4Wld6sWLohT3364E=
=v5oe
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Translation

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/30/2014 04:47 AM, Stephen J. Turnbull wrote:
 Guillaume Libersat writes:
 
 I've done exactly what you said (splitting commits between
 effective translation work and code/template instrumentation) and
 submitted a Merge Request there ( 
 https://code.launchpad.net/~glibersat/postorius/i18n-french/+merge/240066
 ).
 
 Thank you!  My, that was fast!

+1

Thank you very much!

 
 I hope it's gonna be merged soon :)
 
 Me too, but I don't own that repo.
 
 Florian?  Terri?  Can you review soon?

Yes, I can do a review. I'll let you know once it's merged...

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUUpvNAAoJEEceGbPdavl7Qp0H/3+KUV0ebSg7H+UcJRuLac1J
kOV1FeQrY4WwDevF4T21fKCGcCsrMpNIWqYIP457eovNkvmXIAJ6u0F7scmdQiNi
4WGmzFgdU+4g64lEzm9eJmzCg0t8GhdHUnPLWIFgh5k29ukrpU4UPZQvhFH7wBgl
+7euN6BQUKYVIcfo8yKnU8OdVHg8BsOCuu0YuwZ7r1ckIK+rdaEtYktYnHkmc8Ek
NM/s2AXiG4ppVAl0cgbG63ECpnYxy3ca0d9tAgYPWLm5db6lniOjLnOUEnW+hWeK
DUf7xZRllu8yuapd86w2aXRNg1tfKQk0KldUKZWUK8pfUjVULvFcwjWSeFsDI7s=
=PRo0
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Proposed incompatible changes to the REST API

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 08/26/2014 11:59 PM, Barry Warsaw wrote:
 I'm considering making two small incompatible changes to the JSON 
 representation of list requests in the REST API.  Here's what you
 currently get (from rest/docs/moderation.rst) for a held
 subscription request:
 
 dump_json('http://localhost:9001/3.0/lists/a...@example.com/requests/1')

 
address: a...@example.com
 delivery_mode: regular display_name: Anne Person http_etag: ... 
 language: en password: password request_id: 1 type: subscription 
 when: 2005-08-01T07:49:23
 
 I want to change the 'address' key to 'email' and remove the
 'password' key, e.g.:

[...]

 I'd like to just get rid of these and break compatibility, but if
 it would cause pain to Postorius or other tools, I can deprecate
 the old names and remove them in the future.
 
 Let me know what you think.

We're still in beta, so I think breaking backwards compatibility is
justifiable (we should probably coordinate the release of the affected
packages though).

If we want to make our lives a little easier we could keep the
address and password properties as proxy attributes in
mailman.client to minimize the risk of things breaking. At least for a
while.

In the future (once we're out of beta) we could mabye just bump up the
API version number in cases like that. BTW: Should the API version nr
always correspond with the core's version number? Like core version
3.0.12 = http://localhost:8001/3.0;?

Florian





-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT/dSKAAoJEEceGbPdavl7lHUH/0eLV1tzfogv3MojR2TnK5DF
QS4WlJLU8s+vAZQECjrRKr5kCsiruOteVG3Hm8Ts9HEiMrq4pmjvOKc/oCl3q7C2
Hgo30mm/BCW2ZD4TQ5CCz5Q4eMV5vz01f09YS8alQx57reOx6GqSgcpTJKgjVJz4
AgGBqsDH9fkf8IGRIpoqnC4qwH4W6mofITKXLVDvAv4jHnmQv/VqMn+LN48BysI+
ij/0iH7qadTPlUfvLqv8JMNBzPBgxpEEkyVFVTQcggiwRbXTZDq8IMTBZY5E2hp5
5x4WBiNGdCJp3XwVYfmTC0/VwyM6WXbYTWDkuLhhM6iczBzdpWc+EjWNyeVtKLk=
=uUdq
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Virtual Mailman hackathon this weekend: Mailman Suite package!

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/13/2014 09:55 PM, Terri Oda wrote:
 Here's a short line of schedule in UTC.  Everyone else, feel free
 to add your own planned hours here so we know when we overlap, or
 just drop by on the day if you're not sure of your schedule in
 advance.
 
 Terri : Sat 1700UTC - Sun 0100UTC : Mailman Suite packaging

Florian: Sat 1600UTC - 2000UTC - plus possibly some more time a little
later in the evening: Mailman Suite packaging / work on my Postorius
additional email addresses branch.

See you tomorrow!
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTI3XEAAoJEEceGbPdavl7QP8H/3Es3LgPE4KQmSg25TSoRcsn
5D4VYQ10gGT74kl1VirQSQaoyL2FWXxkOHK+hS+U4vxPClHorF8FCOhztrJ22aIp
uNteGnrvld34aEfPrknTvrOCmZ4+bWDwrFo1yZH0GEMiANuQD+IGENOLfdPkib7U
NCBU8SCPE5aT+XA7huY8nZKPr/P/x2K4UMqF97T+loc/KZapD2/pIzRPzYAK7bs2
r0AqfE0+yyb9l9eMybwwVZN+L4u2ahu3YOeDkvlXlqsmc9U8E1pstEBDMeB9iCo1
sFDbTL7+zDzhkDb7T+gT7AgWYAvy8Mbr4QIduU4U8ms1BTbaeRnqnHSsJv4llW0=
=wyy6
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/13/2014 05:41 AM, Bhargav Golla wrote:
 Regarding your second comment, I indeed took Terri's suggestion
 about Intel XDK and am evaluating it while I am writing the
 proposal. And I have missed out Postorius responsive UI project
 idea. Thanks for pointing it out.

The two project ideas (Cordova app vs. Postorius responsive) are
similar to some extend, but with significant differences. Let me
highlight some of them:

Both projects will make you write a good amount HTML/CSS/JS code, as
Cordova also uses these technologies for the user interface. Ideally
(if both projects are implemented - which isn't very likely) the UI
should not be much different - no matter if you open Postorius on a
phone's browser or use the native Cordova app.

1. Postorius responsive
The Postorius responsive project builds on an existing (Django)
back-end that is ready to be used. You might need to implement *some*
backend features, but (in contrast to the Cordova project) especially
the authentication/authorization part is something you will not have
to worry about because the framework already takes care of this. You
can concentrate on the interesting UI parts and make everything work
nicely on a variety of different devices. Oh, but please don't
underestimate the amount of (really very interesting) work you can put
into making a site really usable with either keyboard, mouse and fingers.

2. Cordova app
The Cordova project is different in that it doesn't build on an
existing underlying back-end, which means you will have to take care
of the communication with the core, as well as of authorization.
Mailman's REST API is mainly built for local use, giving you
wide-ranging permissions by default (meaning: if your credentials are
ok, you can do everything). It's definitely not advisable to expose it
directly to a phone app and then let this app manage the permissions
(because that way all users could make themselves admins by
manipulating the app's source code). So what's needed is a layer in
between (and controlled by the site, not the app). This could be
implemented as part of Postorius, but it could theoretically also be
something else on top of the core's REST API. Which one would first
have to be discussed (there are good arguments to be made for both
scenarios). So, in the end, the Cordova project will not be a pure app
project.

Hope that helps.

Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIhdvAAoJEEceGbPdavl7LwAH/2tCr/NgpaD1PbygPEV1LVVP
9PGybptYEFX95eBZoZ6ZXGdOM5y1emBiNhvnoiQT8ciGYnnfqFo9yG+vlHUBbvnp
HEDvzERoYPmZs7uHTLslvqXxpoPeFNbB8Zqk9bWKZdnCa8IRNmwCj87XzKYzMCYC
PyMmpSx3/ypjYJOoyGDsDtJkSmKKX+ZyzETHL+A/N1rA/06Ic2xNhWlyqe64GDu/
N2D+wo2Qw0+DQa80733HXdHoJn/7Us4w0ed1TU58PAbRBMBhfPi69yTOH4LRgWeS
Kq7EmyaEpKOl0n12sOQv65BOxC6Y5Oryka2wkefgTsSzzTIQo8jx8BHKXXXWJww=
=eMLU
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote:
 Rajeev S writes:
 Also, I did not quite get the *coming up with a **great layout
 * part. Do you mean to build a custom shell for mailman? If yes,
 what extra functionality should it provide than the standard
 command line tools?
 
 I think that probably is what he means, but I personally don't
 think that's appropriate.  If people want a CLI with layout
 (which I agree is plausible), what's wrong with Postorius via Lynx?
 (Florian?)

No, that's not what I meant (using the term layout was obviously
confusing - sorry for that!). I think we're talking about two
possible, but very different concepts of a client here:

One is the one-off command (with options) that outputs a result,
either on stdout or saved to a file. This could make for an
interesting project, but I think then it would really make more sense
(like Steve said) to extend the existing `mailman` command instead of
writing a new one.

The other (and the one I had in mind) is a tool you invoke with a
commando which then offers a interface a little different from that of
your standard terminal shell (bash or else). Just like you invoke the
mysql/sqlite3 client (with a db name or file as option). What I meant
by layout is really the question what happens after one starts the
tool by typing something like `$ mmclient --list=f...@bar.id` or `$
mmclient --domain=python.org`, not the actual visual representation.


Does that make more sense?

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1
s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws
YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn
8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424
1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT
q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c=
=ufWT
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Gsoc idea discussions : Continuous integration tool

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/22/2014 07:54 AM, Varun Sharma wrote:
 Hi all, I am interested in continuous integration tool as my gsoc
 project and would like to discuss further it's possible
 implementations. I think one possible implementation for gatekeeper
 is :
 
 Making another django project mm_gatekeeper which every developer
 must run in order to commit to trunk. We can host its repo of on
 launchpad. It will act as a proxy to bzr and will perform bzr
 commit only after all the unit and doc tests succeeds.
 
 
 bzr pull can be implemented as
 
 $ mm_gatekeeper PROJECT_NAME pull
 
 or to pull all projects
 
 $ mm_gatekeeper pull
 
 
 Instead of using bzr commit in postorius we can use
 
 $ mm_gatekeepar PROJECT_NAME COMMAND
 
 $ mm_gatekeeper postorius commit -mcommit message
 

I like the idea of having a command line tool to run integration tests!
It could be used both by the devs working on the different packages as
well as on a central ci server that runs those tests regularly. But
I'm not sure it should be tied that closely into the commit/merge
process:

When a developer works on a new feature in a branch separate from the
main line, it's probably very common to commit small changes that
would break the whole system, but are commit-worthy anyway because
they sum up a small series of changes in a chain of more commits that
eventually lead to a mergeable state.

So when I (as a developer) *think* my stuff is ready to be merged into
trunk, *that's* when I would like to check if everything's fine and
run the integration testing tool.

Another thought: What versions of the various Mailman packages should
the ci tool test against? Should that be configurable for different
test scenarios? Like:

- - Use the branch I'm currently working on, but get all other packages
from their respective main lines (the perspective of a developer
working on a new feature before merging).

- - Use the current main line of one package, but everything else from
pypi (the perspective of a developer when preparing the release of one
package)

- - ...?

Why would you use Django to build the tool as opposed to just a
python package?


Cheers,
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFEvWAAoJEEceGbPdavl7UPMH/A5cd7PWdw+qMaOFRfxfTVuV
lvwdwTOb/Z7oeeE5bol/czvuG7ejaBi5fVxerSb2Ffo4N8aESP1gmxt4U+Qp1SFr
0oIORix0L35Kz19MurbODaZzphjZB5Hf/F/Fu0OgbS4KmDf1nnMvVvXusB6vOxM4
lvg/AOb1GyGuYd78Cj4GA2CY6oCfh2pAjmzUKI4ULvzHjGFHYtjanmYgaB+cjdwB
mNaZbJtQKcjBTvl6iXAON0MU2SzmMG9psA/LcR2hRQMZncBxe0Lbh3fEAA7IHuKe
rzqT2lyX3cBZtvsH06TlLwYmxyJp8Z3HTv6Txj7y+YvvrL4Sj5c6fYTts7OtE1M=
=fci5
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/25/2014 03:17 AM, Rajeev S wrote:
 Hi,
 
 I am Rajeev S , A CSE Undergrad from India. I would like to work
 with the Command Line client project listed in the GSoC ideas
 page.
 
 I have been working on the Postorious package lately and have
 managed to make some tweaks in it, like the add users by file
 upload and an improved email validator.
 
 As a part of the project, I would like to build,at the minimum,
 the functionalities listed at the 
 mailmain.client/src/mailmanclient/docs/using.txt
 
 Can the mentor of this project elaborate upon the requirements of
 the project?

I think the functionalities listed in the mailman.client docs are a
good orientation point, because those represent almost everything the
core REST API currently exposes. It also makes sense to use
mailman.client instead of writing new code that handles the HTTP stuff
and object binding.

I guess the most difficult part of this project is coming up with a
great layout, possibly borrowing stuff from other well-known command
line clients (mutt, mysql/sqlite3, the ipython shell, lynx etc.).

Of course there are bonus points for all kinds of stuff, like
exporting data to files/stdout, making the tool extensible etc. But I
really think designing the right interface and implementing most or
all of what mailman.client can do will take a good amount time.

 Also I have thought of an approach for the full anonymization
 project.Is it possible that I can work on both of these as a single
 project?(I have a feeling that the CLI is a small project, am I
 right?)

You should definitely pick one project and come up with good ideas for
that.


Cheers
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFGH3AAoJEEceGbPdavl7ZYIH+gJVB27H6G5LXd+0+vytx1gC
sZiQCy/vYEr8jtCbe8BdoLvk+jyBNRaUzaxDuL/9Pb3g8HCwuJQ+HzEQm25ewZ0X
vlvWZ7dW07sEYr5q7cRatkqO/GQc2n6B6IgGd3oTkihQUO4iZQTu/ddytMghvCP0
MYtuQyuecjZm8JBlCn6AU0KQWxNx/Kt7CsuPfk6FcCOmA15ZEnZ4kxZFY0khVY5a
NLetoDDY7fQAf5fFlea8SfIN8PFB1i4qv5DdjDaX17Yg/S+X5S0nZx18uvqX7Up8
RlGLTCSA8s3qsYItaI9NWpXRdo/Z1p8MN/hQOOot85e3SVernKn9oq1TSI/7lww=
=pozr
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/03/2014 03:11 PM, Rajeev S wrote:
 Hi Florian,
 
 I had discussed about the full anonymization project with Stephen
 and I had found that I had quite misunderstood the use case of that
 project.
 
 So I have decided to go forward with applying for the mailman
 command line client project.
 
 The deliverables of the project would be, at the least,
 
 * Command line tools to perform tasks in the mailman client docs *
 Any Extra useful functionalities that can be identified, such as 
 export, backup * Other Useful tools like backup and restore. * Man
 Page entries for the new commands

Sounds good! But make sure to mark steps 2 to 4 as optional.

 Also, I did not quite get the /coming up with a //great layout /
 part. Do you mean to build a custom shell for mailman? If yes, what
 extra functionality should it provide than the standard command
 line tools?

I don't know if I would call it a shell, but something like that, yes.
I talked about it with Patrick Koetter a while ago (who is also a
possible mentor for this project), and we had something *a little*
similar to the mysql/sqlite3 client in mind. Similar meaning: You
start the client (possibly providing some context option, like the
database used) and then perform operations on a given context/object
(in our case: lists, users, addresses, preferences) using predefined
commands.

Ideally, the application makes all operations pretty easy, by using
auto-completion, a good help function etc.

This is just a rough idea though, maybe you can come up with a better
one... ;-)


Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFYUaAAoJEEceGbPdavl7jEEIAKJa5XMXRXp9HxJsQgyurZi+
YHqbJlGGNPG0eXOkHS2gdkNXp36cwSLgtKZM/1Xj9pvgnj5+MKlMg8528iGUNqDU
WUdQlIcWLsVovy0m3ANI77k8I5TBFCl8vX4X0NuR05H6RmqwjtlWs9ZnFXlPnrtd
atMCXm7JkEwubTcI+m6I5utLDNzmNLzPwRekFX9umcMR1DXmIDm5v8cE16+DWLmj
ZO5Fj83OH8pA6sUvucfR6YddbDlgRsVfC6K88j2yHFl+0GUeYwIoKPHFXu49/zj+
ThcnNkhx4nMiJlKh41urxA27ysvCavbhgjGvehwWp6eDHBQT29lJtBPEWKRRryM=
=AY/u
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Implemented Mass Subscription via file upload

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/22/2014 01:45 PM, Rajeev S wrote:
 Hi,
 
 I have implemented a mass subscription via file upload feature for 
 Postorious which can be found here.

Thank you very much! This is a very useful feature.

 https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk
 
 How am I to submit a merge request to the Postorious repository?I
 tried to propose a merge via the launchpad, but says the branch
 cannot be merged.

@Mark and Steve: Thanks for helping sorting that out.

@Rajeev: Got the merge request. I haven't had the time to test it yet,
but will add further comments on launchpad as soon as I have... Thanks
again!

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTCxF/AAoJEEceGbPdavl7PhIH/1RIJRdsdWAVe/2vnBGbWTwK
kO9rCNfD9oUb/BGQb3uzoc1RPJUnTq9DQ/yUtiJTAP5zI0NFdyTGcxsDt6raV87P
tUL3nyMtwkDlncm6sFQyb2BYGvdSw6+n7U/YFJpnt67blBb36uUYT+ddFms0UQSF
u7w6iwlMDxB10TcR7IwQaqr+nFCgXhEi73l/knBKpBjTeoODcMbDvq+SVvua4I+x
SOtU34LTu3IQLHN8sLH/VZn16kRdrY+fkQhTtXv8lk6kjayVAetzwtmy2j5A6sAk
KjYlQfgzMsuw0R3pnqW3z0Q9tcIxQh7ht3m8IkKAXq9rwzoFwG2CZndKh9Z4VDU=
=/V/K
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] GSoC 2014

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

the not so good news first: We didn't get accepted as a mentoring
organization for Google Summer of Code 2014.

*But*:

The good news: The Python Software Foundation was more successful
(congrats to Terri!), so we'll be able to participate under their
umbrella again. \o/

We are looking forward to seeing many great Mailman-related project
proposals that we can mentor submitted to the PSF. So let's start
discussing project ideas and let's have another great summer of code!

Cheers
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTC7GCAAoJEEceGbPdavl7mccH/RaIrs7JhSp8I6fOQNF4dbps
GFFD9vTGAo/cR+FMdoS0ryp+Rmr8Un328EabRdgcCmONz5JfBA1dQQGybucy7cfZ
dn2LBAJUjR4fPAT9ETPXTIW8zeapna910QSsoiA1q10se850cr55NEPtqy4sdF96
x8dil/U43aYajJFuusmmJo/W7Kl2V3exEbi5vA2Vhzc5Joutfd9qJq/d140mmMXM
2fY1wm28m+oB59ja5e/pJjhG33X6Mma8ilYsr3ihdftyGoJzIYPsbydeuYoHxDD2
JBC+Gcx5OoLHKyojT1DybHnnAKuteNoaDO/DbpTTf54VN+RpTgh4KLE/hU8Qdmw=
=XTdZ
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSoC 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/07/2014 10:22 PM, Patrick Ben Koetter wrote:
 Dunno, if this is there yet, but a command line client for admins
 that allows to create lists, configure them via list templates,
 backup configs etc. would be a nice thing to have.

+1!

Maybe starting with a local version first (meaning: running on the
same host as Mailman, with unrestricted REST API access -- I guess it
might be enough work for one GSoC project to build a nice CL interface
for the most important functionality). But with an option to add
remote access with more advanced authentication/authorization at a
later time.

 Personally I would also like to see SNMP support to monitor mailman
 in larger installations.

I'm adding it to the ideas page. Would you like to provide a short
description of what you have in mind, so I can add that too?

Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS9+9jAAoJEEceGbPdavl7ACQIAKToWKOZpVu73XyGRgLKTD1b
892v/2xfli2HUUjU/Pb4JfGAZGen0GcPNtsjahy8THcRHy0RIJ+3RrrTrfCErZ9Y
THkyu0uILaZLqOrr9TMvyUkmF0DQXZF0IdgzeYel/WZVL/EC5NHxFldHv4LnnNX8
25cMhxlOW8VJzrUoeP3qBhrwhXe4kMB9PUa8onxgWlvT47P1zNcCLeyb3LBPcphO
0P3iZOgT+nlVn1ZFFrqOT7d3+r2MFYRQz7ltMu3RSwwkXKC0Cq2nfIbtYYtPue2h
az6JPfStGZChq/sQCa5Nqz4JwNc1XW+fo7Qx6YKEuHZxXP4HyGG/c5yI0MuLFwU=
=83sc
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSoC 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/06/2014 08:21 PM, Barry Warsaw wrote:
 2. A responsive ui for Postorius
 
 Very much +1.  Another thought would be to support an app that you
 could install on Android or iOS (or Ubuntu Touch? :) to more
 directly control a Postorius server.

Also a great idea! I think using Apache Cordova for that would be an
interesting option. It's a native app container around a HTML/JS
engine, so one can build native apps with HTML/CSS/JS. Supports
Android, iOS and, yes, Ubuntu, plus a few others. I heard a lot of
good things about it from a friend who has used it recently.

We would need to get the public API working though...


Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS9TwbAAoJEEceGbPdavl7hrUH/jOPOcLl5f0i/PtC+dmxA1E3
lHyYN8pEF5gSYZ4LQfTYIdjBy5yFxVT3kmhNSm8q9TcRB0yYXYsaDBam2GBcrJyU
5utrP5fqtKXDWRe7yZ2k4316tdG8x0ljTwRDeth1IFiEAIqEs1S9ph7xdReA/mry
PVTo1VRjoSXGOryilxDR4RQ151xILooN+R0zw8KoAEcBhSU9oi7ZF8LBop7E1+1a
87/scF7qNTm+4H+0G2/2f5JO+/Cpi2iQvChN2Y6w0OHzhuF1270InN1yz308Qcmp
7TJpkvtQ4DGYV+7C0LbOT5IKKvlOtPvE7nmvPCeBeBdqCUAWEuROL6E2HYb3oSM=
=+I6D
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSoC 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

some project suggestions for this year's GSoC:


1. A continuous integration tool for the Mailman suite.

Mailman 3 is based on 4 different packages which are developed
somewhat independently: The Mailman core, Postorius, Hyperkitty and
mailman.client. It's not always guaranteed that these components still
play nicely with each other after a new commit.

It would be very useful to have some mechanism that runs a series of
tests to make sure everything's not fundamentally breaking. This could
be everything from a command line based tool to a full-fledged
integration into something like Jenkins.


2. A responsive ui for Postorius

In 2014 a web ui should be equally usable on a desktop computer as on
a phone. Nowadays the CSS mechanisms needed to use the same HTML for
different devices are pretty well supported across browsers. I'd love
to be able to use Postorius (and Hyperkitty!) on my phone without
constant zooming.


3. Various Python 3 ports

The goal for the Mailman core is to support Python 3 in the near
future, so Postorius/Hyperkitty/mailman.client might be ported as well
(probably supporting both 2.6+ *and* 3.3+ in order to not frustrate
folks who use additional Django apps that haven't been ported yet).
Not sure if this should be one single GSoC project or one for each
package...


4. Postorius: Improve the test suite

Currently Postorius' test suite consists mostly of unit-tests, using
nose as the test runner. The test coverage could definitely be
improved. It might also be nice to add some doctests as a developer
resource.
This project could also feature some interface/navigation testing,
using Selenium, casperJS or similar.


In addition to these there are a number of project ideas that didn't
get picked last year:

http://wiki.list.org/display/DEV/Google+Summer+of+Code+2013#GoogleSummerofCode2013-ProjectIdeas

My personal favourites:

- - Migration Scripts from MM 2.1 to MM 3
- - Design interface themes for specific types of list
- - Enhance List Style Capabilities
- - Full anonymization (obfuscating sender addresses)
- - No-logging mode
- - Log monitor


Any comments or (even better) more ideas?


I am planning to complete the ideas page by the end of the week
(probably over the weekend), so I can submit our GSoC application on
Monday or Tuesday... Of course we can theoretically add more after the
deadline, but since the ideas page is the most important ingredient of
the application, it would be *a lot* better if we had all projects on
it before Friday 14.


Cheers
Florian




On 01/09/2014 08:28 AM, Terri Oda wrote:
 I've had prospective Google Summer of Code students emailing me
 since, uh, September or so... so I guess it's time to talk ideas!
 
 I've set up a wiki page, as usual:
 
 http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014
 
 But let's start with here: what small projects would you like to
 see us sponsor this year?  I think we'll need to be more selective
 about the final list, but let's start with some brainstorming!
 
 
 ___ Mailman-Developers
 mailing list Mailman-Developers@python.org 
 https://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: 
 https://mail.python.org/mailman/options/mailman-developers/flo.fuchs%40gmail.com

 
 
 Security Policy: http://wiki.list.org/x/QIA9
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS89A5AAoJEEceGbPdavl7kYAIAJFnVk3GwHVOJ1/xEQQogGd7
ted1MsA4QoDPPcqEDASN0SxpsYFIFLPHpPA9J58783pQN0bQ85iQphd3GyE5Ihg9
LLlJgkrmSyS2u5dX70RSSfN2r56wZ81aqVygWVPZA+xoNOnxossJqe1aK5rPrxnH
xIyKtIfsn80Yi876SCB81sAN2kYS7A6NXJ7kF+krpMRW+c5rkkrnLSRPcH0PMIhs
P423f+Q0IVTM+8+vK2MYdmCOCWc01ZrvNGbIBl4Q9t0kBtQ/3hHfjYlpaiSq1x6n
InTbkgiX0Sd6lq5at3GyK/Ud5WC58OnTQEXm2qjkPHNGJPqF31hYKc97CChIveY=
=1amL
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] GSoC 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02/06/2014 07:22 PM, Máirín Duffy wrote:
 Do you know if Summer of Code students can do interaction design /
 UX stuff? Because I'd be willing to mentor for that.

Oh, that would be great!

I'm not a 100% sure about the exact criteria. I vaguely remember a
discussion on the GSoC mentors list about CSS which eventually turned
into an argument about Turing completeness and what constitutes real
programming.

So I don't know if a pure design/CSS project would qualify. But I
think any UX work on Postorius/Hyperkitty will involve at least a
little bit of Django and/or JavaScript work. I'll scan the mentors
list archives if I can find something - or ask that question again,
just to be on the save side.

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS89zRAAoJEEceGbPdavl7vrAH/0rru3C6TtS5RP66h3onx6te
v+9ODFthhH4X4igbElIaI5THa2p8W9d3ukabN9JtvUPhdSSCzWxCn4JsFNJhhqa7
nxQ36cTeR/QPXs49MBBMVTtQPXN7vAC11OgIgOLmkYRrI0hFOQnOOliXflYy7ho6
RSxzHPpsUw48ASYryODfWOSBE1F0yk+fc4p4fWoQZsvGnR56U3y7PV39FLJdWAvq
vdXTqHzX/rzHJyd1njfLO36SFQ0p+rDQNHZXrQJ/Ul5r3le2m1yrxD65WIjn1HAb
frFD4V8RI+CHAP+PSbpJ3E8hBi5/CUVUKqnoZD9ShZ948wpQEIxYRIzXKUImPcE=
=auR2
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman web UI Error

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 01/30/2014 12:40 PM, Kevin Ratnasekera wrote:
 Hi, I am Kevin Ratnasekera, Undergraduate from University of
 Moratuwa Sri

Hi!

 Lanka. I am currently developing a Cloud connector for mailman 3
 as part of my internship project. For this I am using the REST api
 for mailman-3.0.0b3. I am currently following this tutorial 
 http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running

 
and I am getting this error while creating a new domain, user , list etc.
 
 NameError at /postorius/users/new/ global name 'utils' is not
 defined

Unfortunately you ran into an error that just got fixed yesterday.
Updating your postorius branch should fix that (bzr pull).

If you're especially interested in using Mailman3's REST API, I'd also
recommend taking a closer look at the Python bindings (mailman.client
on launchpad - docs are in the repo's src/mailmanclient/docs
directory). It's a Python wrapper which makes accessing the REST API
pretty easy.

Cheers
Florian




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS6r6nAAoJEEceGbPdavl7ObsH+QHD48xlDqEVCw/qk88OCvNM
oMeJJeuJM7qournaRofCjNp8Z3JWUlltXGIBMd4iKPsIjmUdNQPTwXaxUeRJb3vD
XeVw26ThLzNbjocxcM2HtgOKFwJrPcX6Ov/H0JLsNIwA83V9fClxbEuJ60LNNQ7r
DFJLiqwsozJbOz1khBqjyyg/xbIhcTIko9Yo+jJyqzgEdNhv0gUBYtsJN/xOJZVB
YD2MwqlFt7UVKrQIpjyZ1ceZz6PZaZnYgAxgKY2DjApChqbbA5lFnhgtcKtYwAZN
CqEWJ2juB71dGmBSsG8f7ThrLmERKYCICft8iOPnRLhV/xjtWgoP8j7E+SiR6E0=
=yTb3
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman Suite Beta task list take 2

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 11/20/2013 04:28 AM, Terri Oda wrote:
 Trying to keep track of what's still on the table:
 
 1. Multiple email address association with a single account.
 
 We're going to implement the verification emails from postorius for
  now, I guess.  Florian, you seemed to know how to do this; do you
  mind getting it done?

Yep. I'm on it.

 2. Authentication issues for Postorius/Hyperkitty
 
 Have these been resolved?  Florian, do you need code reviews yet?

The code itself is working and tested
(lp:~flo-fuchs/postorius/postorius_persona). I wanted to add some more
documentation before requesting reviews though. Will probably get that
done until the end of the week I think.


 4. Owner/moderator removal in Postorius
 
 Unless someone is desperate to handle this one, I may do it this 
 week, either tonight or Thursday.

Great!


Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSjJNNAAoJEEceGbPdavl7FxkH/3rKV5vTVwWbnkcHsFvvw7gV
EHTYgho20cEW2mvYpikc1efUEKsmAqayFBe0Vj/MdS64k352snR9stwN+GKGq/VT
Fb7Mk5frEgpKPgj0iIz4pF2BMYo/LV6Ao9sR80R5ssrrk+H0V2syF/4Nx0S7Mfc/
sGC8Bc5v7bXEiCkFZ++U1sySu/0L8z78B+QwVJNbtT95wwbFIOEoJGE6lDA19Uq0
WF9iGhfSaR5UBOTeK797lNRN0pCUtv9X8mZgU+MMOOG9Y965Jl+nCEltnq90ut1k
cELJK2v08WWr39PHuzfj+D1wSG3rym7L5Y9ZIORz/DwLm2jqnyqM185WJUBC2vU=
=xkiA
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman Suite beta: what's left?

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 11/13/2013 01:29 PM, Ian Eiloart wrote:
 Repeating what I already wrote for completeness here: Migrating 
 and then going back all at once is not necessary.  You can
 migrate bit by bit, although it may require a little bit of
 manual fiddling if you get to the point of installing both on a
 production server.
 
 
 The tricky bit here is the continuity of the web interfaces. If a 
 list manager is used to going to
 lists.example.com/Mailman/listname, and they have that bookmarked,
 then they’ll want to keep going to that same place.
 
 Likewise, with the list archives, and all the list users. We have 
 1312 lists, perhaps two or three thousand list admins, and tens of 
 thousands of users.

Postorius' URL config does allow for some customization, but I doubt
it will be easily possible to style list summary URLs to match the
MM2-style mailman/listinfo/{list name} URLs. The reason is that
Postorius uses the list-id property as unique identifier in URLs
which is generally different to the list names used in MM2-URLs.

What we could do though (possibly as part of the migration routine) is
to auto-generate rewrite rules for major web servers like
Apache/nginx/... redirecting MM2-style URL requests to the new ones
(using HTTP status code 301, which would also tell search engines that
the change is permanent).

Florian



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSg4EdAAoJEEceGbPdavl7Yr0IAJn5zGRIpu0T9JqVqfZA9S92
eL5b4NI7J8XqxC/0zQpqTUfAV8NOoxCORfY8YTx7ClDbitFJzEVPAa+/95x8w7w/
2jqBtpktnBRa5TlLWubK+odXdPi/z01cj2VxkbOZq42VJu2kG97usHux7nGhR9K4
2SOGA3J735kjoKA60FNKVVSCjX4/TXSy42WINe0mlWQ0OVmD0Nza2xwoHWQLlaN7
Pe+/32FJlWr+x0QX+Tdp3qh9R6v9MHdsY7LluddTnpNx4Lss/KR+pS7390wzuWxx
eIhaTAlWE6Ix2fCHGrVB67wxyH6MktNwbBqeUj4nXccfga7yVNRJfEncMdoOGDg=
=ZeDC
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

Re: [Mailman-Developers] Mailman Suite beta: what's left?

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there...

On 10/29/2013 10:35 PM, Terri Oda wrote:
 Stephen, Florian and I had a nice discussion at the GSoC Mentor
 Summit about what's left before we can release a beta of the entire
 Mailman Suite (i.e. Mailman core, Postorius and Hyperkitty packaged
 together). We're getting close!  In fact, close enough that I'm
 going to suggest that we set a beta release target date of Dec
 1st.
 
 I know we had a list of 5 things... but for some reason I can't
 remember all of them.  Florian, Stephen, can you chime in?
 
 
 1. Need a Postorius interface for associating multiple email
 addresses with a single account.  This is probably going to require
 either an email verification, so we might want to have that as part
 Mailman Core rather than doing it directly in Postorius.  Short
 term, I don't care how it's done as long as it verifies that the
 user actually has access to the addresses they link together.

Short term we could use django-registration to verify additional email
addresses. It should be very easy to integrate with Postorius. Plus
it's maintained by one of the Django people so I guess it's stable
enough to work even long term.

 2. Postorius  Hyperkitty need a bit more work on the
 authentication management.  Florian indicated that he's looking for
 some code review for the persona integration and that we'd really
 like a single sign on solution for postorius/hyperkitty to work
 together seamlessly.

I got a branch almost ready (90%-ish) for merging that contains A) a
change from our current Persona integration (django-social-auth) to
Mozilla's own django app and B) some code to take domains created in
Mailman-core into account when verifying Persona tokens. Since this is
a security issue, I'd really like to have a second set of eyes having
a look at it before merging. (Yes, I'm especially looking at you Dr.
Terri! I'll poke you when I've added the remaining 10%... ;-) That's
next on my list as soon as I have reduced my current
post-travel-pile-of-errands a bit.

Re: Hyperkitty: Last time I checked it didn't seem to implement any
access control for non-public lists. This isn't really a bug, but it
restricts HK to be used with public lists only.
@Aurelien: Is that correct? If so: Would you mind me suggesting some
ideas to add member checking for private lists?

 3. We need some nice install scripts or packaging work so that 
 installing Mailman Suite is easy.  Probably for beta purposes this
 can just be a shell script, but we also talked about doing a meta
 Mailman Suite PyPI package and maybe doing a .deb or .rpm as
 proof of concept.
 
 4. ??

I'm not sure, but I *think* I mentioned I wanted to add some changes
to Postorius' test suite before releasing the beta. Which isn't really
a *feature*, more like an itch that needed scratching. Anyway, I
merged that one last week.

 5. ??

Owner/Moderator removal. It's essential, but implementation-wise
that's a minor thing.

 Hopefully Florian and Stephen have better memories

Well, I'm not sure myself if items 4 and 5 were really the ones we
talked about... ;-)

Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScs9fAAoJEEceGbPdavl74X0H/1Rafly+Cyhu6zb+MkSPur8U
rbmDrYjZEhfJiATBWZxT3w85f/oLHVPUfPtEHcfxAUR32OwI4ZTPSYot05gqCzqZ
dnb55XHbMkFAOx9BjrrV3ncau/rUie6MR2cIslQRoegFtaG7X9euRcw1P3qi5Ppp
C96L8ZFgPeuynjdy2sAs8zRNDhhsgs+Nq8bWneZBQtsy+AAjJKnrQMlNzxtGSZi2
gVCvcubj66zrxl4k/yXUzVNgvtm9fT64NvtAVch5Duo4zh4TUjdANAzNDHTR/jk7
yVZ1bqW9Rvq5ttzaaYjMUiGD8LLYWHhsRQK9+FyEw3y5OZoonGE7Li2TNX+L0QY=
=7wnE
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

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

[Mailman-Developers] Mailman Hackathon this Sunday (July 21 2013)

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

We're going to do another IRC Hackathon this Sunday for all things
Mailman! This time we'll start around 0700 UTC and will stay until 2300
UTC. Please join us, no matter if you need advice, want to have some
code reviewed (GSoC midterms are approaching fast!) or just like to hang
and see what everyone else is working on.

Most of the Mailman mentors and developers are going to be there (we're
distributed pretty much around the whole planet, so not everyone's gonna
be there all the time...).

So save the date: Sunday July 21 2013 0700 - 2300 UTC on #mailman
(on freenode).

Please note that while current GSoC students (both under the PSF and
Systers) are especially encouraged to join, this event is for everyone
interested in developing anything Mailman-related.

Oh, and here's the link to that awesome timezone converter Terri dug up:

http://www.timeanddate.com/worldclock/meetingtime.html?day=21month=7year=2013p1=394p2=37p3=248p4=263p5=1038iv=0

Hope to see you on Sunday!
Florian


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR6F5fAAoJEEceGbPdavl7P1EH/0cROuMotLQbvz/yM1nkT5kn
I37EtxW+1rXQXzotL1HZxSmFaI85iXR9bOhLqcKZkSswIL5HhUlXeIztx216RpSh
A09K3gu6u7kFOvITkaZIA/26r0uNLbTyGsqjLZqCJbqtpSF6FHBqQdsAFQD8fNsq
BiOP1VEv76Q2Cdaxyd4eDzmdH635Feb1xf3s8UvaDuILWQebZlGgxAhJmwbpe96H
E4lKAzMJD4bH3NpImWa98EAi1OqmBULtzEChB6t76jt3eEp3xUpIm8zMM+CA0xsf
q+AxOaMR11I+y1iPHX54xatS0UelBhQIearm0jSHsSqjATgArf8u6J7LNdkxyrY=
=qBFY
-END 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] GSoC discussion

[Florian Fuchs]

2013/5/7 Manish Gill mgil...@outlook.com:
 Hey guys. This is in response to Richard's email for project discussions.

 Richard and I have been having discussion regarding how to proceed with the
 project and he has been very helpful in getting me started with the project.

 Right now, I'm focusing on the internal data representation of various
 Resources in the system and how they might translate on an API level. So,
 for
 example, in trying to expose `MailingList` objects, as of now, there is no
 way to
 post messages to a list externally.

I don't know if posting messages through the API is a priority. I'd
suggest to start with the more fundamental functionality, like
creating domains/lists, list configuration, subscribing and
unsubscribing, adding owners and moderators, moderating subscriptions
and messages.

Regarding owners and moderators: It's true that the core's REST API
does not expose them as single models, but as membership records with
a 'role' attribute. Postorius reflects the same role system
(admin/owner, moderator, member) that is currently implemented in the
core (which is also kind of well known from Mailman2).

In Postorius, the permissions that are granted to each of these roles
are static, for example a moderator can moderate messages as well as
subscription requests, but it's currently not possible to create
groups of moderators that can only moderate messages *or*
subscriptions. In theory it would be possible to ignore the roles
given by the core and grant more fine-grained permissions to separate
groups or users. But (at least for now) Postorius does not do that for
various reasons.

There has been some discussion on IRC and elsewhere if the public API
should be implemented as part of Postorius (as the project title on
the ideas page says) or as separate app. My personal opinion is that I
don't have a problem with any of the two options. But I *do* think
that if we provide an official admin web ui and and official
public facing REST API, both of them should reflect the role system
reflected in the core and both should have the same authorization
logic -- meaning: A list owner/moderator/member in Postorius should be
allowed the same things as a list owner accessing the public REST API.

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] Architecture for extra profile info

[Florian Fuchs]

Hi,

some first thoughts on it:

1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.

2) Like the core, it should implement a Python-based webserver.
It doesn't need to run on Ports 80/443, so we don't have to care about
one of the popular web servers already listening to those ports.
Also, we definitely don't want admins to have to follow another how
to setup mailman.users with Apache/mod_wsgi howto.
It should just run if someone says start (Maybe it can even hook
into $ bin/mailman start? I know, that contradicts item 1. ...).

3) It doesn't need Django.
Since it will not deliver any HTML (except an oAuth login form -- see
5.) and it doesn't need to be integrated into any existing web site,
we can choose a more light-weight framework.

4) Adding new content types for user records should be easy, but
clearly defined.
We don't know what information applications need to store. Icons,
essays, avatars, IRC handles, Twiter names, ...
So we might think about using a schema-less database, but: We don't
want to make it possible to just manipulate the result JSON and POST
it back to the resource, possible deleting things other apps need. So
adding new information types should be a separate process.

5) It should implement an oAuth provider.
This could be used for API authenticaion and to log into
Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
We won't need this for a first prototype though. For now we're
probably fine with 6)

6) Like the core it should be accessible with BasicAuth from localhost.
Ideally, in the future, it should be accessible both via BasicAuth
from localhost and via oAuth from the outside world...

Please correct me where I'm being stupid!

Florian





2013/4/18 Terri Oda te...@zone12.com:
 Background for folk new to this discussion:

 Currently, all user information is stored in Mailman core, but it's minimal:
 a real name, a set of email addresses, subscription info, and preferences.
 Barry suggests that it should stay minimal: only the things Mailman needs to
 know to correctly deliver mail (which actually doesn't include real name
 but let's leave that as a legacy item for the moment)

 It's pretty likely that future features of Mailman will want to attach extra
 information to users.  Some of it will be social-y stuff like user icons for
 HyperKitty to display in the archives. Other things include metrics like
 when did this person last post to the list? or how many posts have they
 made over the lifetime of this list?  One thing I know of is that Systers
 requires a short essay for all new subscribers, explaining why they want to
 join the list.   (And they're considering porting this feature to Postorius,
 which means we potentially want an answer to where will the extra profile
 data get stored? before their students start coding.)

 So...

 I think we've sort of agreed that it would be best if whatever we built just
 had a rest interface and hyperkitty/postorius/whatever would talk to it
 through there, and could share data that way, but we need a simple prototype
 that folk (particularly students) will be able to start using, and there's
 still some internal architecture decisions that need to be made.

 Does anyone have time to build such a thing or write up some short
 architectural documents so a student could build such a thing in relatively
 short order?  It doesn't have to be the perfect final design, but we
 probably need a basic starter api for adding, accessing, editing and
 possibly even removing profile data.

 Thoughts?

  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/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] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Stephen J. Turnbull step...@xemacs.org:
 Florian Fuchs writes:

   5) It should implement an oAuth provider.

 I don't see this.  Mailman is an auth consumer.  The only people
 Mailman can provide auth for are the site admins.  Everybody else is
 more or less untrustworthy.

 I can see that there are applications where it would be useful to have
 an auth provider bundled with Mailman, but I think implementing it is
 somebody else's job.

   This could be used for API authenticaion and to log into
   Postorius/Hyperkitty

 I think generic auth provider is overkill for these purposes, and a
 trap for anybody who thinks we know enough about crypto/security to do
 this stuff well.

I agree it's probably not easy. And, yes, maybe we need someone to
help us with that.

But maybe we can take a moment to think about the usefulness of such a
feature and the possibilities this might open up, rather than
dismissing the use of a certain technology right off the bat. If we're
unsure we can implement this in a secure way, we can still say no to
this. Also, who says such a feature would be enabled by default? We
can add it as an experts only thing and leave it up to the admins to
make sure they use it in a secure environment.

I remember several discussions during PyCon(s) and on IRC where
scenarios of different mailman instances talking to each other came
up. Of course that doesn't mean implementing  a generic oAuth provider
is the only answer to this. If there are better and easier solutions,
fine.

Luckily going beyond localhost isn't something we need for the
prototype that Terri suggested to be built for GSoC.

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] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Richard Wackerbarth rich...@nfsnet.org:
 On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:
 3) It doesn't need Django.
 Since it will not deliver any HTML (except an oAuth login form -- see
 5.) and it doesn't need to be integrated into any existing web site,
 we can choose a more light-weight framework.

 Here I take exception. Dismissing Django is a restriction that unnecessarily 
 affects the ease of implementation and, in the common case, complicates the 
 integration of the functionality.

 Although it could be implemented without Django, it could also be implemented 
 as a Django app.
 An instance of a django server can then serve the functionality.  As an 
 alternative, where appropriate, this app would directly drop in to an 
 instance of Postorius or an enterprise website.

 One of the advantages of Django is that it can be used as a rapid prototyping 
 mechanism. Simplified interfaces to the data are free and more elaborate 
 ones can be added in an incremental fashion.
 Also, rather than writing custom modules for things such as authentication 
 and REST interfaces, there is the large community of third-party extensions 
 which readily integrate to provide that functionality.

It's not that I don't want to use Django. I just wanted to point out
that we won't need much of it for a pure JSON API. OTOH adding a new
dependency by using another framework is probably not a good idea
either. So if we want to keep the number of dependencies low, the
alternative would probably be to use no framework at all and use
restish for the, well, REST stuff (or whatever library the core will
be using in the future).

Florian

 I would advocate that this User module make it appear as if stores the 
 entire record for the user.
 In the implementation, it could actually store parts of the user information 
 in multiple databases (one of which could be the MM-core).

+1
___
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] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Terri Oda te...@zone12.com:
 We're probably going to be running around with a bit of a hack job for the
 user database in the near future (either done by a student who needs it in a
 hurry or done by one of the core devs to support a student who needs it in a
 hurry) so while I don't like to design on the assumption it's going to go
 wrong, I think in this case planning for a redesign might be prudent because
 it's pretty clear we don't actually know all our requirements.

I think in this case it makes sense to spend a more time on the API as
seen from the outside (urls, methods, json responses) than the actual
implementation. If the API is good, it's totally acceptable if the
underlying implementation will be redesigned later.

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] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Richard Wackerbarth r...@dataplex.net:
 Yes, yes. Please re-invent the wheel once again.

 And while you are at it, you might just remove the dependancies on zope and 
 storm, etc.

 I think that you are missing the point that, at this time, this is intended 
 to provide the capabilities that MM-core chooses not to implement.
 Those website components (HK and Postorius) are being driven by Django and 
 you only make it more difficult to implement them when choose a different 
 schema to model/present the data.

I don't want to re-invent the wheel and I don't advocate dismissing
Django. Django is probably perfect for the prototype. It might also be
perfect for the final thing. But we don't know what database we're
gonna use in the end (which determines if the Django ORM still fits),
or if we'll use many HTML templates etc. If we end up not using many
of the things that make Django great, we might wanna think about if we
want to use it. And might still come to the conclusion that we do. All
I'm saying is: The environment for such an app could be a little
different to Postorius/HK, so let's spend some thought on it. Is this
such a bad idea?

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] Regarding Authentication of REST API

[Florian Fuchs]

Hi Manish, hi everyone,

2013/4/10 Manish Gill mgil...@outlook.com:
 For the GSoC REST API project, I've been wondering about how
 authentication would work.

 OAuth is a way to go if we want authenticated/signed requests. I have a
 few questions regarding that.

 - Will Mailman core become an OAuth provider, with Postorius/API being
 the consumers?

Probably not the core itself, but possibly another yet-to-be-written
application that Postorius, Hyperkitty and other clients could use. We
had a long discussion on this list whether to build a central
application to store user data that can be accessed by the different
Mailman-related applications. While we haven't decided yet whether or
how to proceed, this would possibly be the right context for that.

 - If the answer to the above is no, is the plan to support populer OAuth
 providers like Facebook/Twitter ?

Like we discussed on IRC earlier, it would be nice if a site running
Mailman could act as an oAuth provider. Especially since the thought
of a FLOSS mailing list manager requiring an account with a commercial
oAuth service provider to use its API might seem a little odd. But
implementing both the provider as well as the client is probably way
beyond the scope of this GSoC project. Especially since authentication
is only one aspect of it.

 (If not, can you guys please explain how would the authentication
 protocol really work?)

 - Since Postorius is already using Mozilla Persona, can that also be
 used to provide authentication to API clients?

Probably not Persona, which is meant to be used in the context of a browser.

But are we sure oAuth is our only option in an API context? Are there
other opinions?

 - Am I over-thinking this? :)

I don't think so. It's not exactly obvious.

BTW, the oauthlib documentation has a nice overview over the different
oAuth workflows [1].


Florian

[1] https://oauthlib.readthedocs.org/en/latest/oauth_1_versus_oauth_2.html
___
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] Interested in - Better User Settings Management

[Florian Fuchs]

2013/4/15 Sneha Priscilla 24.sn...@gmail.com:
 Hey everyone!

Hey Sneha!

 I had introduced myself earlier on this list but I guess I can do it again.
 :)

Sorry about that -- and thanks for writing again!

 I'm Sneha Priscilla, a final year undergraduate CS student from
 Bangalore, India. I was a previous Summer of Code student for Systers
 last year and I have in the process,  worked with a lot of Mailman
 too.


 I am especially interested in Postorius and would like to implement
 one of the following ideas this summer:
 1.Better User Settings Management
 2.Design interface themes for specific types of list
 3.Enhance list style capabilities

 The one I am most interested in is 'Better User Settings Management'.
 I'd like to know if it's a feasible idea for this summer and how
 important is it on the list of project ideas for Mailman this year?

It is certainly a priority in Postorius, because it's one of the last
missing features (and we're about to add a very simple version of it
in order to be able to release a new beta soon). The core's
architecture allows very fine-grained changes to a user's settings,
like (but not limited to) the ones described on our ideas page.
Because of that complexity, one very important aspect of this project
is to come up with interface ideas that will not leave people confused
(or how Terri described it: the user interface nightmare). So I
think it could make for a very interesting summer project, both on the
architectural as well as on the coding side.

Overall I'd say it's probably one of the more important project ideas,
although that definitely depends on who you ask. ;-)
Also, it's a bit difficult to categorize the project ideas in
important and less important ones. Even a project idea that hasn't
been in the center of our attention can suddenly become very important
if we receive a great application for it.

 Also, since this is something which could also serve as an important
 Systers project, is it viable to be joint mentored by Systers and
 Mailman?

Not officially. We'd have to decide if Systers or the PSF would be the
official mentoring org.
That being said: What's the harm in more than one person giving advice
to a student? As long as there is one person who is formally in charge
and is committed to keep the ball rolling.


Cheers
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] Interested in - Better User Settings Management

[Florian Fuchs]

2013/4/15 Robin Jeffries ro...@jeffries.org:
 As someone from Systers, we would probably accept her under the Systers
 umbrella (though if we get a lot of great applicants and are feeling
 squeezed, we might come to you to ask you to use one of your slots for her,
 but Terri is the one to broker that), but we'd want to make sure there was
 someone on the mailman side who could help her get unstuck at various
 points.  We did that last year and it worked well.  (as you know, Florian)

Oh, I hope I didn't sound skeptical... This particular project (being
a Postorius one) affects both Terri and me, and both of us have been
mentoring for Systers as well as Mailman. So either way this should be
especially easy. But as you said, Terri is probably in the best
position to make a suggestion regarding which org's slot to use.

Florian




 Robin


 On Mon, Apr 15, 2013 at 12:31 PM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/15 Sneha Priscilla 24.sn...@gmail.com:
  Hey everyone!


  Also, since this is something which could also serve as an important
  Systers project, is it viable to be joint mentored by Systers and
  Mailman?

 Not officially. We'd have to decide if Systers or the PSF would be the
 official mentoring org.
 That being said: What's the harm in more than one person giving advice
 to a student? As long as there is one person who is formally in charge
 and is committed to keep the ball rolling.


 Cheers
 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/robin%40jeffries.org

 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

[Mailman-Developers] Mailman/PSF GSoC Students: Next steps

[Florian Fuchs]

Hello prospective GSoC students,

there are roughly four weeks left until the application deadline on
May 03 2013. Sounds like a lot, but it time's running fast. ;-)

The application period opens on April 22. Ideally, you should already
have a pretty good understanding of the boundaries of your project
proposal(s) around that time. So use this week and the next for
further discussions, ask questions, do some reading. This will give
you a better feel for what the overall work load might be (which is
crucial for a healthy project timeline).

Most important, don't worry about sounding stupid or not knowing
something! There are several moving parts inside the Mailman software
ecosystem and no-one expects you to grok everything right from the
start.

Once the application period has started, it's better to apply sooner
than later. Don't worry if your application is unfinished -- it will
be editable until the deadline (at which point it must, of course, be
complete). But it's better to have it in the system early than to wait
until the last minute. Just leave a note saying it's still in draft
status. We will put an application template on the wiki to give you a
rough outline of what we expect the applications to contain.

Lastly, to avoid possible confusion: The mentoring organisation you
have to apply with is the Python Software Foundation. Since the PSF
handles a lot of sub projects like Mailman, it'll be a good idea to
put Mailman in the title of your application so we can find it and
nothing gets missed.

Cheers
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

[Mailman-Developers] Mailman participating in GSoC 2013 under the umbrella of the PSF

[Florian Fuchs]

Hi everyone,

the list of organizations accepted for GSoC this year has been announced,
but apparently google-melange.com suffers from a little end of countdown
stress and only displays a small number of them. So a quick announcement
for those of you currently watching that page:

Like last year and the year before, Mailman will participate in GSoC under
the umbrella of the Python Software Foundation! Yay...!

(Of course it would have been even better had Mailman been accepted as a
separate organization, but unfortunately that's not the case. Maybe next
year!)

So let's have another great three to four months of learning and coding and
doing beautiful things!

Cheers
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] GSOC 2013 : Authenticated REST-API in Postorius/Django

[Florian Fuchs]

Hi Rahul,

2013/4/6 Rahul Gaur rahul@gmail.com
 So , last night I tried my hand on django-rest-framework [0]  and TastyPie
 [1] as well.

 What I could figure out with my two quick and dirty hands on applications
 of both the frameworks , the django-rest-framework is a bit more lengthy (
 but those few extra lines are for the best) when stacked up against
 Tastypie.

 I wrote this quick django app and then I tried to write API's for that app
 in both the framework.Both the frameworks have there own advantages lets
 talk about that.

Thanks for creating the two examples! I took a quick look at them and
it looks like both frameworks are pretty easy to use if a resource is
based on a typical Django model. The Mailman resources OTOH are not
retrieved from a database but from another API -- Mailman's core REST
API that is only served locally (postorius uses the mailman.client
library to access that data). Which of the two frameworks would you
consider more flexible if you want to get your data from anything else
but a Django DB model (I *think* Tastypie has different classes for
model resources and everythingelse-resources)?

 *$ curl http://127.0.0.1:8080/formpost/ -H 'Accept:text/html'

 The Django-rest-frameworks  API's returns web browsable representation of
 the data by default :)

Sounds nice! :-)

 So , the confusion I am facing here is that the Postorius is already mature
 and stable app and while playing with the two frameworks for API's  what I
 figured out is that if I opt for django-rest-framework , I would need to
 write new Views ?
 But if I go for TastyPie , I won't have to touch the existing Views and
 write authenticated API's.

 Hence to implement authenticated API's , which one would be better ?

Hard to say - judging by how they're used in the examples, both look
good. But there are some more things you might want to consider before
choosing one:

Authentication methods
Which auth methods are provided out of the box by the frameworks? And
which one(s) would you like to support (OAuth(2), BasicAuth over SSL,
...)? I guess choosing and implementing authentication could become
one of the major sub-tasks of that project.

Support for Django 1.5 and Python3:
At some point in the not so fare future mailman and postorius will be
ported to Python3. Django 1.5 already supports Python3, so it would be
a bonus point if the rest framework supports it, too (or if their
developers are making efforts to do so...).

Another idea (not sure if it's a good one): Maybe also take a closer
look at Django's class-based views. They are capable of routing
requests to the same URI to different dispatch methods, depending on
the HTTP method. So that might be also be an interesting option.

Cheers
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] error while setting up mailman on ubuntu please reply

[Florian Fuchs]

Hi Ashesh,

it looks like installation of one of the dependencies is failing, but it's
a little hard to say which one and why (at least to me).
Maybe there's a buildout expert on the list who has seen this kind of
traceback before and can provide help right away...

If not, could you provide us with a little more information:

- The revision number your mailman branch is at (type bzr log -l1)
- Your default Python version (type: python --version)
- If we're lucky, the tempfile that failed to be executed still
exisits ('/tmp/tmpu69D_h',
see the second to last line of your traceback) -- maybe you can post the
contents of that file to some paster service and send the link. If it isn't
there any more (most definitely after a reboot), you could run bin/buildout
again and use the new file name from the bottom of the traceback.

Another idea: Have you tried installing mailman inside a virtualenv?
Also: It looks like you're running the installation as root. It should work
without root privileges.

One last thing: We're currently working on simplifying those complicated
installation instructions (aka create non-homicidal install docs ;). So
don't give up now!

Cheers,
Florian





2013/4/1 Ashesh Vidyut ashesh.vid...@gmail.com

 i m following


 http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running

 i had brached mailman

 after that i excecuted python bootstrap.py

 in bin/buildout

 i get

  An internal error occured due to a bug in either zc.buildout or in a
 recipe being used:
 Traceback (most recent call last):
   File

 /home/ashesh/mailmanc/eggs/zc.buildout-2.1.0-py2.7.egg/zc/buildout/buildout.py,
 line 1923, in main
 getattr(buildout, command)(args)
   File

 /home/ashesh/mailmanc/eggs/zc.buildout-2.1.0-py2.7.egg/zc/buildout/buildout.py,
 line 466, in install
 installed_develop_eggs = self._develop()
   File

 /home/ashesh/mailmanc/eggs/zc.buildout-2.1.0-py2.7.egg/zc/buildout/buildout.py,
 line 707, in _develop
 zc.buildout.easy_install.develop(setup, dest)
   File

 /home/ashesh/mailmanc/eggs/zc.buildout-2.1.0-py2.7.egg/zc/buildout/easy_install.py,
 line 871, in develop
 call_subprocess(args)
   File

 /home/ashesh/mailmanc/eggs/zc.buildout-2.1.0-py2.7.egg/zc/buildout/easy_install.py,
 line 129, in call_subprocess
 % repr(args)[1:-1])
 Exception: Failed to run command:
 '/usr/bin/python', '/tmp/tmpu69D_h', '-q', 'develop', '-mxN', '-d',
 '/home/ashesh/mailmanc/develop-eggs/tmpNyd439build'
 root@av:/home/ashesh/mailmanc#


 how to solve this ?
 please reply
 ___
 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/flo.fuchs%40gmail.com

 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] Error in Archive unpack while setting up mailman client 1.0.0

[Florian Fuchs]

Hi Mahendra,

this seems to be caused by the mocker library being distributed as a
bzip2 archive. A while ago another developer ran into the same problem and
solved it by installing bzip2 separately and then switching to python 2.6
(IIRC). Obviously being stuck with py2.6 is a less then ideal solution, but
if you can wait a little: I am currently doing some work on mailman.client
to prepare for the Pycon development sprints starting on monday. Part of
that work is replacing the mocker library with another one called mock,
which is distributed as a less exotic gzipped tarball. This is no solution
for your general problem installing bzipped python packages, but at least
it will most probably solve this particular issue...

I'll post a message here when I'm done...

Cheers
Florian




2013/3/14 mahendra singh meena mahendra00...@gmail.com

 This is my first time I am setting up mailman.Using step-by-step
 procedure from
 http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running

 when i am doing :-
 $ cd mailman.client
 $ python setup.py develop

 I am gettin following error :-
 ...
 Processing mocker-1.1.1.tar.bz2
 error: Not a recognized archive type:
 /tmp/easy_install-kM8hYI/mocker-1.1.1.tar.bz2

 Any clue how to solve this ?
 I asked the same on irc but i feel its quite inactive might be due to
 the time-zone difference with other developers.

 One more thing that I noticed during the same step is when it
 downloads mocker and other requirements using script

 python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/package_index.py
 It takes proxy not into account when opening url in
 open_with_auth(url).So, I think we shall modify it to take proxy
 option also.

 Please guide me if I have skipped any point or taken a wrong step.

 Regards
 Mahendra
 ___
 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/flo.fuchs%40gmail.com

 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] PyCon US 2013 sprint wiki page

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 02/16/2013 11:46 PM, Barry Warsaw wrote:
 On Feb 16, 2013, at 01:22 PM, Terri Oda wrote:
 
 Since I was already poking around in the wiki today, I set up a
 page for the PyCon 2013 sprint next month.  I'm claiming that
 Barry and Florian are coming 'cause I'm pretty sure they said
 they were, but if the rest of you would like to announce your
 attendance or start suggesting things we should be discussing or
 hacking... here's the place to do it:
 
 http://wiki.list.org/display/DEV/PyCon+Sprint+2013
 
 Thanks for setting up both of these pages Terri.  Yes, I will
 definitely be there.

I'll be there, too. Flight's already booked and all... :-)

 I've linked from the Pycon sprint page to this page:
 
 https://us.pycon.org/2013/community/sprints/mailman/
 
 I've also added some sprint topics that I think would be great to
 work on. Tops of my list include:
 
 * Get Postorius feature complete enough to release

Absolutely! That's definitely my first goal. If there's some time
left, I'd like to take a closer look at Hyperkitty and discuss ways to
bring Postorius and HK closer together, especially their user models.

Looking forward to see you guys there!
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRIo5JAAoJEAszfsgOAINuPiYH/3b3r8/JRipaAtDE0IJZCjhV
1Uru+ppoZOo8VPtUH7uJ3jAMQgGiJshebq5oQdEHUB9ZEoxDxqiqRX81V+O4641w
ya34gmlgRXkMMlntlnQ7m+OxeJDCjug4kVUIBgrhpnEv/3MU4qBDryXVLSStnwTW
M9/95otdygI2OnoPBiWI8+n0C2+8odvaHFZoBmPoHg2iL8NDQlDTGatnDdoQYxAA
2/nVzxreUU8I9vvDCk7f8ysz6DkQEYhGFhfQYtb2d9mvZbmCkOpZTVVFrpE/HRY0
4c4HYsXal6Vz9NGmUPAoHW9uxFbh6gGTQwQ0ArKGpSM0sUdzT3XCmML0WHZjzT4=
=AUkq
-END 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] (no subject)

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Sandesh,

is it possible that bzip2 is not installed on your machine?

Florian


On 02/18/2013 07:12 AM, Sandesh Agrawal wrote:
 While setting up postorius, i am getting the following error during
 this step sudo python setup.py develop as given in the link : 
 http://pythonhosted.org/mailman/src/mailman/docs/WebUIin5.html
 
 -- Processing
 mocker-1.1.1.tar.bz2 error: Not a recognized archive type: 
 /tmp/easy_install-xxvsrr/mocker-1.1.1.tar.bz2 
 -- 
 ___ 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
 

- -- 
Florian Fuchs
Heckmannufer 2
10997 Berlin
0176 - 206 408 12
030 - 301 367 56
flo.fu...@gmail.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRIpKpAAoJEAszfsgOAINu7mEIAMCB1aCpOlWXA5aWTNyYoNvA
JWn5rxQd9vsKB5NM4yJv5/QRYsgX3DEfrHdiU53i8YiopLSZkL5FbWMsQ99J4a/C
d6wT9y0NG4w73QZXW8rdqtVlNsBhigX69z96u0/iaQMqz581f0kDE8UvZ2llQDdm
SPbWgBhUrR1avEApS7jP9mwuLWJPO/pZBud9CSzRneph0+kfyyEGzwck4GEfzhSs
pZbsZZKbsl83/eKct8ixc3Opkq4akE81qa+egqYStpsd+b3Qw5yut+hvogsmI/kb
fxWI6Ke6hyEkn0fy9y6auuKo5a05yUfggJLQ2KjojiPS0FCp2iSUPRFlPiumGjg=
=kiya
-END 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] HyperKitty : VCS change

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Aurélien,

On 01/09/2013 03:46 PM, Aurelien Bompard wrote:
 We're concerned however by the uncomfortableness it may cause you,
 the Mailman community, if/when you want to contribute to
 HyperKitty. Barry, Terry, Florian, would that be a problem ? Others
 ? Of course I'm ready to merge patches sent by email or bugtracker,
 but that's a little more friction.

No uncomfortableness on my side. I'm used to the occasional Not a
branch / Not a repository error when when switching between
projects. ;-)

I guess for the most basic use cases it's not that hard to get up to
speed with either bzr or git. And a world where there's only one VCS
to rule them all that everyone's fluent in is probably far away (and
maybe not even desirable?).

Cheers
Florian





 
 It's not a speak now or forever hold your peace moment, but this 
 unnecessary complexity is tiring day-to-day, so I'd rather sort
 that out quickly-ish.
 
 Thanks !
 
 Aurélien ___ 
 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7aQkAAoJEAszfsgOAINuzWwIAJGwQGxc+BLFhVAkbCtEi8gM
iOTiqEp3gkKN/zxACP8I8LLESSTHWCj5tWBFmvyBFYb04wANPv1YhTB7elNX8zZj
/xZnbB/XQzdY/7Fvv0QKJQHFFS5hEwpbF8osxlyA4NrbdEXIvSveWhI8Gf4h2re/
LUQJsWOOmGgBHSKGcdA0dxBD0j1KPs2dvSEH8Z0YG1t5XpHwZLqvL/rxupgXVQwT
Aau3g0LESeioQenZJKzCGNAOS8tF3A7JputDssGTgWYP3yqLpe0UdPZFEjtvSTRg
JEw8ikWZc5YAvtHth4YJCA+5/qC2uq4ye0A4gaX527AzOUqAHwKziycrggfut2U=
=a6a9
-END 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

[Mailman-Developers] Reminder: Mailman/Postorius/Hyperkitty hackathon

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

this is just a quick reminder that we're having another virtual
hackathon tomorrow!

Personally, I'll probably start hanging around on #mailman on freenode
around 13:00-ish (UTC).

Hope to see you tomorrow!

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQy2oxAAoJEAszfsgOAINuJ2IH/RaY9wrVzVUPDqNkCLi36NoE
PPmmOadmmu1jrz37bok6t1HKy50mr3OBx1ZhYiwYGIHvXejjfLBFty7buEPE/lMu
XNe9+/maT9LU9zBV2iKKBuJQdzDls8C1cOSR71uxaqo/vJNORYZLAH6C7gH6usby
DzIZ87zjfQWtJje1yg+1djf/CsSD4rLT65941S5ehIiQoWqitQOS5BAQLDQlAdo8
KR8hvX92QtSyva0Fffa/3etK2JudYic0f8volPbbAdND4/g0ZDzpeWlGESO5vFu1
u01i2h/jaKHmoELsvKSkKv4ckyZPEMNeZc04cagpbvhRY+1TQBRXJ0EPYLr0Wps=
=YYG1
-END 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] Listadmin and other alternate interfaces for Mailman

[Florian Fuchs]

Hi,

On 10/26/2012 08:15 PM, Barry Warsaw wrote:

One thing we need though is an authenticating proxy for the REST API so that
non-localhost users can script their own changes to lists they own or are
members of.  We can't expose the admin REST API to non-localhost and I really
don't want to have to add the authentication layer to the default REST API (at
least not right now).

It's possible that such an authenticating layer could be implemented as part
of Postorius, since I think Django supports REST also, and you'll *have* to be
authenticated to interact with Postorius.  OTOH, it would be nice if that
could be provided without requiring Django.


Of course it would be nice if a public API wouldn't require Django. But 
we already have authorization functionality for all kinds of roles in 
Postorius. And to add a JSON API shouldn't be so hard.


In fact, I played around with this a little over the weekend. I didn't 
want to change too much of the existing authorization system, only 
slightly enhance it to provide a simple way for non-browser clients to 
log into Postorius with existing user credentials. What I came up with 
is a simple view decorator that checks for an HTTP Basic Auth header if 
the current user isn't logged in and uses these credentials to start a 
new Django session. Clients that can handle session cookies can use that 
in all concurrent requests (which makes it a little faster). Clients 
that don't support cookies can just send the auth header again with the 
next call.


Theres also an API resource that returns a json string with all mailing 
lists (very similar, but not identical to the one the core API returns).


If anyone's interested: I added a small proof of concept for a command 
line client to a private branch on launchpad. It's far from mature, just 
to see if the idea works... 
https://code.launchpad.net/~flo-fuchs/+junk/mmremote. (Please make sure 
to use the latest revision of Postorius).


Another thought: We will add some convenience AJAX functionality to the 
Postorius UI. For this alone it's worth having a number of JSON 
resources available. In other words: Postorius would be the first client 
to use its own API :-)


Cheers
Florian









Cheers,
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@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

[Mailman-Developers] mailman.client

[Florian Fuchs]

Hi there,

I've just pushed some small changes to mailman.client. So for everyone 
taking part in tomorrow's Postorius hackathon: Make sure you have the 
most recent revision of mailman.client installed. Otherwise Postorius is 
not going to work fully with the recent version of the MM3 core.


Looking forward to seeing you tomorrow on #mailman!

Cheers
Florian

P.S.: @Barry: Is there a way to get the list_id property from a list 
resource in the API? The JSON returned by /3.0/lists/fqdn_listname 
doesn't seem to contain such a field. So in order to make mailman.client 
work with 3.0b2, I simply used fqdn_listname and replaced the @ with a 
dot. Dirty, I know... But only a preliminary hack until I know how to 
get the list_id from the API. ;-)




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

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

Re: [Mailman-Developers] Getting to Mailman 3.0 final

[Florian Fuchs]

On 09/18/2012 06:26 AM, Terri Oda wrote:

That said, I'm tentatively planning a personal postorious hackathon all
day Saturday the 22nd.  If anyone wants to join me, I'll be on #mailman
on freenode!


Excellent idea! I don't know yet how much time I'll be able to free up 
on Saturday, but I will definitely show up on IRC some time during the 
day...


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

[Mailman-Developers] Postorius: Missing Features (Draft)

[Florian Fuchs]

Hi all,

in order to give everyone interested (and everyone joining this 
Saturdays's mini-hackathon) something to code, here's a list of existing 
Postorius features, followed by a list of *some* missing features. Of 
course, the second list is up for discussion - ideally it should 
transform into a concrete what Postorius must be able to do-list 
before Friday, so we can file bugs on launchpad and assign them.



1) Existing Features:

* Add/Remove lists
* List overview (shows all public mailing lists).
* List info/subscribe/unsubscribe
* Mass subscription (admin only)
* List members overview (admin only)
* Held messages/moderation (admin only)
* Edit list settings (list identity, autoresponse, digest. moderation - 
admin only)

* Add domains (admin only)
* Authentication through BrowserID or a Postorius admin account (created 
during installation).



2) What's missing:

* Adding/editing users
* Editing user data
* Assigning roles to existing memberships (member/owner/moderator).
* Access control based on membership roles/superuser status.
* Membership moderation
* Better/more help/success/error messages
* Better test coverage
* OpenID Log-In
* Registration without BrowserID, OpenID?
* Anonymous subscriptions?
* Translation?

There are, of course, many more possible features, but I'd consider 
these the essentials. I'm also sure I've missed something important... ;-)


Cheers
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] Getting to Mailman 3.0 final

[Florian Fuchs]

Hi,

On 09/17/2012 04:50 PM, Barry Warsaw wrote:

Maybe now that the core is pretty close to what it will be like when released,
we can get more volunteers to help test Postorius, and perhaps contribute to
it?  It would be cool if we could do a simultaneous release, but OTOH, the
architecture of MM3 expressly encourages separation of the web ui from the
engine.


I suggest, a good way to move forward would be to define a list of 
missing features and criteria we agree Postorius will need at a minimum 
to be worthy of being released alongside MM3.


Since I guess that not everybody is aware of all the existing features, 
I can prepare a list of those (as well as some comments on problems or 
decisions that need to be made), so we don't start the discussion with 
It needs to be able to create new mailing lists.


I can't do that *right now*, but most definitely tomorrow.

Cheers
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] Sample / dummy / generated data for mailman?

[Florian Fuchs]

Hi Ethan,

if you work on the Python side of Postorius, like Barry said, you don't 
really need sample data in form of real lists/held messages/etc. 
*Ideally*, the code is covered by tests that don't rely on sample data 
(or even the mailman core) to be present (see an example in the source[1]).


That being said, Postorius is in some kind of transition when it comes 
to testing. We used to have some tests based on the Django test HTTP 
client which tested more or less the whole stack, using a temporary 
mailman database. But this was slow, complicated and error-prone.


All communication with the mailman core happens through mailman.client 
and the data expected to come out of it is pretty well documented in the 
docs [2][3]. That makes it pretty easy to use mock API return values to 
test our business logic (like in the example above). There are also nice 
ways in Django to test login status without touching the database and to 
test response/request objects without making actual HTTP calls. All of 
this can make testing more efficient and fun. I hope we can design our 
future tests more like that (suggestions are welcome!).


OTOH: If you work on the HTML/CSS side it can make your life easier to 
have *some* real data present. You can add lists, domains, users etc. to 
a local mailman installation without having to care about working MTA 
settings. Feeding real emails into the local system is a little bit more 
complicated. Also, it is little fun to compose actual mails for every 
scenario that might be relevant for the UI (overlong texts etc.). I 
prefer to test a design directly in the templates or change the data in 
Firebug or even temporarily manipulate the output of the view code.


Hope this helps...!

Cheers
Florian


[1] 
http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/tests/test_list_members.py
[2] 
http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/
[3] 
http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/mailman/client/docs/using.txt






On 09/05/2012 03:37 PM, Barry Warsaw wrote:

On Sep 05, 2012, at 02:01 PM, Ethan Fremen wrote:


Is there any way to automatically generate lists/messages/members etc?

If not, how do you (existing devs) go about setting up mailman with said
data?

I am interested in working on
https://bugs.launchpad.net/postorius/+bug/1004049 , and so need to add some
emails in pending state. More generally, having a bunch of
lists/users/etc would be helpful in developing the UI further.


In general, I'm not a fan of sample data for tests.  Back in my Launchpad
days, we had tons of sample data that the tests relied on and we had a
terrible experience with it.  It makes tests brittle, difficult to understand
the initial state, very difficult to change or update, etc.  We were slowly
weening ourselves off of sample data by the time I moved on to other
projects.

The alternative is for the tests themselves to explicitly set up whatever
minimal state they are testing, usually in their setUp() methods.  They
typically use the internal APIs (e.g. interfaces and a few other convenience
functions) to set things up, including mailing lists, users, pending requests,
emails in queues, etc.  There's also a test helper that ensures all that state
is cleaned up after each test, and this is hooked into the test layers (though
eventually I'd like to get rid of zope.testing).

The mm3 does have a small amount of sample data, but only for the schema
migration tests.  Because the model can't be used to set up the test state, we
basically create an unmigrated database and populate it from sample data, then
run through the migrations, and test the results through the model.  The model
can't be used to set up the initial state because it already reflects the
migrated schema and because it's Python code, it's not easy to change in the
middle of a test.

I'm not sure how it's done in Postorius, but for the core, you can look
through the substantial amounts of existing tests to see how things are done.
There's probably a bit of style skew with the older tests doing things a bit
out of what I now consider good style, but I've tried to spend some time
getting the tests in a consistent state.

Hopefully that helps.
-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/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: 

Re: [Mailman-Developers] status of mailman 3.0 web stuff

[Florian Fuchs]

Hi Ethan,

yes, the roadmap is probably the best place to get started. It covers 
the bugs/features for the next alpha release - but there are of course 
more ideas that have been floating around. (Yep, Barry, I should update 
the wiki page... ;).


The five minute guide covers the quick installation of a development 
environment (using the django dev server), which is enough get you to 
start hacking quickly. If you plan to run Postorius with a real web 
server, you can find installation instructions for Apache here:


  http://packages.python.org/postorius/setup.html

Cheers
Florian



On 08/21/2012 06:00 PM, Terri Oda wrote:

Yeay!  In addition to what Barry said (join Postorious!) I just want to
say I'm really excited to see you back.  :)

More specifically, though, I think a good first step with Postorious for
you would be to take a look at the current roadmap for alpha2:

https://launchpad.net/postorius/+milestone/1.0.0a2

As you can tell, it's pretty short, but I'm guessing we're missing
things, and it'd be really helpful to have fresh eyes look at it.

The instructions for setting up the interface so you can see what's
already there are here:

http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running


(And I tested the instructions a week or two ago, so if you have any
trouble with them let me know.)

  Terri

On 12-08-21 3:08 AM, Ethan Fremen wrote:

Hi!

I (failed) to help provide a new UI in the 2006 summer of code sprint. It
seems like now a framework is acceptable :) which makes me happy.

I now have a job where I will be coding python again, and I was wondering
if I could help push this forward?  the
http://wiki.list.org/display/DEV/Web+Interface+Status page says that a
basic UI is being set up.

Is there a way I can jump in and help?

Thanks,

~ethan fremen
___
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/terri%40zone12.com


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/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] status of mailman 3.0 web stuff

[Florian Fuchs]

Hi,

On 08/21/2012 04:27 PM, Barry Warsaw wrote:

Florian, perhaps you can update the above wiki page to provide some more
updated information about Postorius?


The page is now updated:

  http://wiki.list.org/display/DEV/Web+Interface+Status

I have added a list of possible/planned future features, not all of 
which have been discussed with the community. Also I'm sure I have 
missed some things that might be important to others. So please see this 
list as a draft and add comments, send posts to this list or just edit 
the page directly.


Cheers
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] Login / User Identification Issues in MM3

[Florian Fuchs]

Hi there,

Am 11.07.12 15:34, schrieb Richard Wackerbarth:
 On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
 Richard Wackerbarth writes:

 What I am advocating is that the core message handler NOT be the
 keeper of ONLY PART of it.

 What I'm advocating (mildly, because somebody else is going to have to
 do the work) is that the core be the keeper of ALL of it.  The core is
 not just a message handler.  It is also a database, containing both
 list information and subscriber information.  

If we're only talking authentication data, I agree.

But I also agree with Terri that there might be a good amount of user
data used by Postorius, Hyperkitty or any other web ui/client that just
doesn't have anything to do with mailman's core tasks. And I don't see
why something like preferred ui theme or profile-related stuff like
irc nick should be stored in the core db.

Isn't it very common that applications combine information from
different sources (databases, webservices,...) in one place (with or
without caching them locally)? I don't see anything unusual in the
concept of having some mailman-related user data managed by the mailman
core and other kinds of data handled by the
database/file-structure/key-value-store/web-service(s) that a web
application is using.

If Postorius and HyperKitty decide to share some information in one
place, because the projects are so closely related, that's of course a
fine idea. But I wouldn't try to cram everything into the core db just
for the sake of having it all in one place.

Florian


 
 OK, so we agree that ALL of the information SHOULD be stored in one place.
 That means that this database will need a lot more information, such as 
 access control specifications, etc.
 Further, it needs to be extensible so that various users can add whatever 
 customizations and extensions they need.
 
 And each of those functions will need supporting views, etc.
 
 Pretty soon, you will find that what you need approaches something that 
 already exists -- a relational database.
 Rather than reinventing the wheel, we should just use an already existing 
 database system and make all of the data directly accessible.
 
 Since a minimum of subscriber information is absolutely essential to the 
 core job, all of
 it may as well be in there.
 
 This does not follow logically.  Since only a minimum of information is 
 essential to the core job, it may well be more appropriate for it to get that 
 information from another source as needed.
 
 In some configurations we will want the subscribers to be authenticated, so 
 we may as well keep all such
 information in the core's database.

 Steve
 
 Applying your previous argument, I could equally say since the web user 
 needs to be authenticated, we may as well keep all such information in the 
 webUI's database
 
 Richard
 ___
 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] mailman3 instance for preview + exploration

[Florian Fuchs]

Hi Jeff,

I am not completely sure, but both the Traceback and the fact that it
worked again after the restart seem to point in direction of the the
django devserver. I'd love to help you setting up postorius with
Apache/mod_wsgi if you like. That would be much more stable than the
built-in server. Also, you'd have much more control over logging etc.

Just email me if you'd like to do that.

Florian



Am 06.07.12 20:20, schrieb Jeff Marshall:
 First, I restarted mailman3 and the error at
 http://mailman3.jab.org:8000/persisted.  Then I killed and restarted
 postorius and the error cleared up.
  The postorius instance is accessible again.
 
 
 
 Postorius output showed (I don't see a postorius output log file anywhere
 so I don't know if I can pull up history farther back?):
 
 [04/Jul/2012 06:05:00] GET / HTTP/1.1 500 93610
 [04/Jul/2012 08:59:05] GET / HTTP/1.1 500 93655
 [04/Jul/2012 09:53:42] GET / HTTP/1.0 500 93553
 [04/Jul/2012 09:56:39] GET / HTTP/1.1 500 93838
 [04/Jul/2012 10:12:32] GET / HTTP/1.1 500 93775
 [04/Jul/2012 10:25:23] GET / HTTP/1.1 500 93655
 [04/Jul/2012 12:25:56] GET / HTTP/1.1 500 93583
 [04/Jul/2012 13:24:33] GET / HTTP/1.1 500 93443
 [04/Jul/2012 13:26:42] GET / HTTP/1.1 500 93443
 [04/Jul/2012 21:50:56] GET /static/postorius/defaultimages/favicon.ico
 HTTP/1.1 404 1803
 [05/Jul/2012 05:39:37] GET / HTTP/1.1 500 93882
 Traceback (most recent call last):
   File
 /usr/local/lib/python2.7/dist-packages/django/core/servers/basehttp.py,
 line 284, in run
 self.finish_response()
   File
 /usr/local/lib/python2.7/dist-packages/django/core/servers/basehttp.py,
 line 324, in finish_response
 self.write(data)
   File
 /usr/local/lib/python2.7/dist-packages/django/core/servers/basehttp.py,
 line 420, in write
 self._write(data)
   File /usr/lib/python2.7/socket.py, line 324, in write
 self.flush()
   File /usr/lib/python2.7/socket.py, line 303, in flush
 self._sock.sendall(view[write_offset:write_offset+buffer_size])
 error: [Errno 32] Broken pipe
 
 Exception happened during processing of request from ('134.95.19.9', 26446)
 Traceback (most recent call last):
   File /usr/lib/python2.7/SocketServer.py, line 284, in
 _handle_request_noblock
 self.process_request(request, client_address)
   File /usr/lib/python2.7/SocketServer.py, line 310, in process_request
 self.finish_request(request, client_address)
   File /usr/lib/python2.7/SocketServer.py, line 323, in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File
 /usr/local/lib/python2.7/dist-packages/django/core/servers/basehttp.py,
 line 570, in __init__
 BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
   File /usr/lib/python2.7/SocketServer.py, line 641, in __init__
 self.finish()
   File /usr/lib/python2.7/SocketServer.py, line 694, in finish
 self.wfile.flush()
   File /usr/lib/python2.7/socket.py, line 303, in flush
 self._sock.sendall(view[write_offset:write_offset+buffer_size])
 error: [Errno 32] Broken pipe
 
 [05/Jul/2012 06:14:25] GET / HTTP/1.1 500 94198
 [05/Jul/2012 10:39:53] GET / HTTP/1.1 500 93559
 [05/Jul/2012 10:51:25] GET / HTTP/1.1 500 93882
 [05/Jul/2012 11:30:01] GET / HTTP/1.1 500 93538
 [05/Jul/2012 11:54:47] GET / HTTP/1.1 500 93655
 [05/Jul/2012 12:09:25] GET / HTTP/1.1 500 94323
 
 
 
 And the mailman3 var/log/mailman.log looked like this throughout:
 
 Jul 04 01:17:37 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org HTTP/1.1 200 307
 Jul 04 01:17:37 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org/config HTTP/1.1 200 1647
 Jul 04 01:17:42 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 jabl...@mailman3.jab.org HTTP/1.1 200 295
 Jul 04 01:17:42 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 jabl...@mailman3.jab.org HTTP/1.1 200 295
 Jul 04 01:17:42 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 jabl...@mailman3.jab.org/config HTTP/1.1 200 1611
 Jul 04 01:17:48 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 public-t...@mailman3.jab.org HTTP/1.1 200 311
 Jul 04 01:17:48 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 public-t...@mailman3.jab.org HTTP/1.1 200 311
 Jul 04 01:17:48 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 public-t...@mailman3.jab.org/config HTTP/1.1 200 1634
 Jul 04 01:17:52 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org HTTP/1.1 200 307
 Jul 04 01:17:52 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org HTTP/1.1 200 307
 Jul 04 01:17:52 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org/config HTTP/1.1 200 1647
 Jul 04 01:17:55 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org HTTP/1.1 200 307
 Jul 04 01:17:55 2012 (10058) mailman3.jab.org - - GET /3.0/lists/
 third-l...@mailman3.jab.org HTTP/1.1 200 307
 Jul 04 01:17:55 2012 (10058) 

Re: [Mailman-Developers] mailman3 instance for preview + exploration

[Florian Fuchs]

Hi,

Am 05.07.12 17:40, schrieb Terri Oda:
 How hard is it for us to make a nicer, more helpful error page for this?

Shouldn't be too hard. I just filed a bug report for this:
https://bugs.launchpad.net/postorius/+bug/1021364

In a non-debug mode environment a 500 error page would be returned -
which is only slightly nicer than what we are seeing now...

  I'm guessing it's going to be a common problem when more people start
 running the two together.
 
 (I know, I know, I should know the answer and be able to write the
 solution myself, but my django-fu isn't quite up to speed yet, so I'm
 asking first.)

This should be changed inside the Manager classes in models.py. If the
error is catched and MailmanApiError is raised instead, the views will
render an error page with a REST API not found message.

Cheers
Florian



 
  Terri
 
 PS - Thanks again to the Jeffs!
 
 On 07/04/2012 02:34 AM, Florian Fuchs wrote:
 Hi Jeff,

 thank you, that's great!

 The Connection refused error is caused by Postorius failing to connect
 to Mailman's rest api. Can you check if Mailman is currently running?

 Cheers,
 Florian

 Am 04.07.12 01:32, schrieb Jeff Breidenbach:
 Hello mailman-developers,

 I suspect that there are folks who would like to see what Mailman 3
 and particularly Postorius without going through the effort of
 software installation. Jeff Marshall was kind enough to set up a test
 instance that people can look at and play with. This is a temporary
 setup so don't use for anything real. Also try not to spam anyone as
 we'll take it down at the first sign of trouble. I hope this helps
 with the development process.

 Cheers,
 Jeff

 ===

 http://mailman3.jab.org:8000/

 username: public-admin
 pw: tryitout
 ___
 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/terri%40zone12.com


 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/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] mailman3 instance for preview + exploration

[Florian Fuchs]

Hi Jeff,

thank you, that's great!

The Connection refused error is caused by Postorius failing to connect
to Mailman's rest api. Can you check if Mailman is currently running?

Cheers,
Florian

Am 04.07.12 01:32, schrieb Jeff Breidenbach:
 Hello mailman-developers,
 
 I suspect that there are folks who would like to see what Mailman 3
 and particularly Postorius without going through the effort of
 software installation. Jeff Marshall was kind enough to set up a test
 instance that people can look at and play with. This is a temporary
 setup so don't use for anything real. Also try not to spam anyone as
 we'll take it down at the first sign of trouble. I hope this helps
 with the development process.
 
 Cheers,
 Jeff
 
 ===
 
 http://mailman3.jab.org:8000/
 
 username: public-admin
 pw: tryitout
 ___
 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] MM3 - Using fqdn in the exposed URLs

[Florian Fuchs]

Hi,

1) We could change this part of the URLs to something like:
domaindelimiterlistname. This way we can compose the full
fqdn_listname from the URL but it's not as obvious as the list's email
address (it's also still readable).

2) Adding to Richard's slug idea: We could provide a slug-field in the
list settings (and create list) form. The default slug is the format
described in 1) - but an admin can change it to any custom (and shorter)
slug they like (as long as it's unique).

I suggest that we save the slug/fqdn_listname mapping in a local db
table (it's only a ui specific setting, so the core doesn't need to know
about it).

Cheers
Florian




Am 12.06.12 05:06, schrieb Stephen J. Turnbull:
 Barry Warsaw writes:
 
   hashing the mlist fqdn and taking a substring would probably be good 
 enough.
 
 Eww!
 
 -1
 ___
 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] HyperKitty login

[Florian Fuchs]

Hi Aamir,

On 05/30/2012 01:45 AM, Aamir Khan wrote:
 Hi everybody!

 First task I am going to do for my GSoC project is to have login
 authentication mechanism for HyperKitty users. I have had discussion
 with few mailman developers about it. I am planning to wrap up
 social_auth into mm_ui_auth django application. Both postorius and
 HyperKitty can use this app for authenticating users.

As you know, Postorius already uses django-social-auth. Implementing it 
was more or less a configuration issue (settings.py), plus we had to 
build a login-template (which was pretty trivial).


We did look at some other existing solutions before choosing 
django-social-auth. So far it seems like a good choice. (Although it 
should be noted, that there was one report about a browserID logged-in 
user getting logged-out erroneously. But I haven't been able to 
reproduce this.)


Since social-auth has been designed with DRY/re-usability in mind, the 
important question (at least to me) is: What are the advantages of an 
mm_ui_auth app wrapper compared to simply using it directly?


The main advantage I can think of is shared UI-resources (template, 
css). But this reduces mm_ui_auth more or less to a theme only app 
(OK, with a few lines of login/logout view code in it). This can make 
absolute sense, but mainly if both Postorius/HK are OK with sharing the 
same design for the login-/out pages. I, for one, would be fine with 
that. (Well, let's see how it looks first. But still... ;-)


Cheers,

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] HyperKitty login

[Florian Fuchs]

On 05/31/2012 10:00 AM, Stephen J. Turnbull wrote:

Yeah, I think all the mentors and most of the other subscribers here
can figure that out. The questions are which one?


https://github.com/omab/django-social-auth


do) and why this one?


It's used in Postorius. There aren't that many around. This one's well 
documented, very comprehensive and works well with django.contrib.auth.



Aamir is explicitly working on HyperKitty.  While it makes a whole lot
of sense for him to generalize the authorization module to Postorius
(and one would hope beyond), this does require communication with the
people doing Postorius.  If he's talked to them and believes there's
agreement on requirements, all I want to see is I've talked to
Florian on IRC about Postorius requirements for authorization, and we
agree that they have the same requirements (see my blog).  Of course
he's welcome to post as much detail as he likes!


Aamir contacted me and Terri via email, Terri told him about 
django-social-auth. So he did start the required communication with us. 
He also talked to some other devs on #mailman about his approach.


Cheers,
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] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Florian Fuchs]

Am 22.05.12 03:33, schrieb Stephen J. Turnbull:
 A different question: what happens if MAILMAN_THEME is set to foo,
 and postorius doesn't have a foo theme?  I think it would be
 obnoxious to require all customizers to customize everything.

That's why I'd like to get rid of the MAILMAN_THEME setting rather
sooner than later. It seemed like a good idea at the time, but that was
in Django 1.2 days. Since 1.3 (with the introduction of
contrib.staticfiles) there's no benefit in doing it like this any more.

If you ask me, Postorius should ship with a default theme and make
alternatives available as installable theme-only apps. If a theme is
available on pypi it takes about two command line actions and one change
to your settings to install a new theme.

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] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Florian Fuchs]

Hi,

Am 20.05.12 16:22, schrieb Richard Wackerbarth:
 However, I am concerned that your implementation exposes /postorius/ in the 
 URLs and in the template names for the themes.

It doesn't - it's a simple configuration issue. The URL namespace for
Postorius is defined in the *project's* urls modules (in our case
`dev_setup/urls.py`), *not* in Postorius'.

You can easily change `postorius` to something else to define a
different namespace for all Postorius-URLs. You can also define
postorius.urls as the ROOT_URLCONF in your project to use no namespace
at all (this would of course only make sense for installation scenarios
where no url-collisions are expected, like a (sub)domain that serves
nothing but Postorius).

Remember that dev_setup is just an example django project that we put
into trunk for convenience' sake during PyCon. It is not part of the
Python-package that get's installed with Postorius. Although, as we
discussed recently, dev_setup should be moved to a separate location.

 
 IMHO, all of this design seems to reflect a philosophy based on the idea that 
 the purpose of the website is to run mailing lists. 

Quite the opposite. The whole idea of distributing postorius as a django
*app* and not a django *project* aims at making it easily possible to
integrate Postorius into existing scenarios. That's why the URL
namespace isn't defined in the app-level urls module.

 I think that we need to look at it from a different perspective. The use case 
 is that of a company, organization, etc. that has a presence on the 'net. For 
 example, their website is primarily an e-commerce site. The company runs a 
 customer contact mailing list to which individuals can subscribe. Here, the 
 postorius interface is a small subsection of the overall website. But, 
 properly written, the display should appear to be a seamless addition to the 
 content.

Absolutely. Both scenarios should be (and are) possible. A stand-alone
installation as well as integrated into an existing django-project.

 This implies that themes would apply to the whole site and not just the 
 postorius section.  As such, I think that we should put the theme definition 
 in a theme namespace rather than within the postorius namespace. 

The URL namespace you choose for the Postorius URLs has no effect on the
theme that is used. You could change the namespace to

(r'^googlegroups/', include('postorius.urls')# SCNR :-)

and django would still look for a template folder with the name
`postorius` (both in your app as well as your project). So overriding
the app's theme (or just single templates) on the project level would
work just like with every other django app.

For instance, you could override Postorius' base.html on the project
level to make it use your existing site's html/css layout.

 
 I suggest that we deliver at least two themes. One would be in the style of 
 mailman and the other that of django. I suggest this because, if we 
 cannot do both easily, it will provide some indication of the usability of 
 our website structure.

We already have a MAILMAN_THEME setting (set to 'default') which you
could easily change to something else and add another theme folder to
the templates/postorius folder. We did that exactly with the idea in
mind to deliver more than one theme with the application.

However, I don't like the idea very much any more, because django
already has a very good system to override existing themes, either
through project-level overrides or through installing a theme-only app.

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] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Florian Fuchs]

Am 21.05.12 18:24, schrieb Richard Wackerbarth:
 I believe that it may be your intention to have kept postorius hidden.
 But I don't think that the actual implementation has accomplished that.
 
 Please see ~mailman-coders/postorius/trunk
 http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/files/65/src/postorius/templates/postorius/base.html
  (revision
 65) at lines 11 - 16

If you are talking about the static file paths containing `postorius` I
don't see why we should break out of this very useful convention (or why
it should be contradictory to the goal to make postorius more customizable).

Having the app name hard-coded in static file paths is pretty common.
And for a good reason - for instance, if you use `manage.py
collectstatic` - which has the sole purpose of making app assets
available within a STATIC_URL/app_name/... folder structure (and is
essential for serving static files effectively and hassle-free).

Do we want to be able to customize the namespace in page urls? Yes. Do
we want to make it possible to override single postorius URLs (for
instance if you just want to use the subsription page on your site)?
Also yes. Those are basic django features and you can do that with
Postorius, too.

But if you want postorius to use different asset paths IMHO the django
way to do it would be to just override base.html. What we could do
though (we already have your bug report for that) is optimize
base.html's block structure a bit.


 And you seem to have missed my point in suggesting that we deliver two
 themes. I recognize that Django has a good mechanism for the
 implementation IF the user templates are written in a generic manner.
 However, all too often, in many projects, I find that the actual code
 written fails to adhere to the necessary standards and is therefore very
 difficult to port to an alternate implementation.

I agree, the goal is to keep the markup in the sub-templates (the ones
that extend base.html) as simple and generic as possible. In order for
them to work well even with a very different override of base.html. I'm
glad for every inconsitency you can find and report on that side (or
even fix it!). I'm sure there are things we can do better. It's still
alpha code after all.

Also, I'm very eager to clean-up the view code and add better testing at
the moment. So we definitely can use some help with the templates.

 If we force ourselves to maintain two, significantly different,
 implementations, we are much more likely to remain within the design
 standards and thus have something that an end-user can readily customize
 for their own use.

I agree - with the small exception that someone has to write that second
theme... ;-)

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] [GSoC 2012] Metrics

[Florian Fuchs]

Am 05.05.12 17:21, schrieb Stephen J. Turnbull:
 Terri Oda writes:
 
   So... If AJAX is the fastest way to get some initial prototypes going, 
   that's a good place to start.
 
 As the author of the original suggestion about AJAXing the charts, I
 don't actually think it is the easiest way.  I think it's easier to
 just generate a fixed-size chart and slam it in as an IMG, and
 generally good enough for the purpose.

Creating JS-/AJAX-ified graphs doesn't have to be hard. There are some
*really* awesome libraries out there (such as flot[1], Raphael[2] or
d3[3]) that make stuff like this pretty easy. (Those three are all MIT
licensed so I guess there should be no collision with the GPL?).

But I would consider carefully where to use or not to use actual AJAX
(meaning: asynchronous server requests). If there is a lot of data or if
the data depends on on-the-fly user inputs (like drill-down charts)
asynchronous requests are very useful. But charts can be fed from many
sources and AJAX is not always the best choice. For example, the
JavaScript application could read the data from a JSON string that is
delivered within the page content. Or it could use HTML5 data-
attributes. Or it could DOM-traverse an HTML table and build the chart
from its contents (that one could also make a nice bare-bones fallback
for non-JS browsers).

As for Geoff's non-JS request: I agree that it's perfectly reasonable to
ask for a non-JS version. But first let's let George be creative and
have some fun. If he comes up with a visualization that gives us
insights we would not get from a simple img or html table I surely
wouldn't want to miss that for the sake of general JS-freeness and 100%
accessibility. There's a reason modern data visualizations don't look
like good ol' analog[4] stats anymore... :-) That said, there are a lot
of ways to create beautiful fallback versions for non-JS (and even
text-based) browsers, and we should take care of that at *some* point
for sure.

Cheers
Florian


[1] http://code.google.com/p/flot/
[2] http://raphaeljs.com, also gRaphael for analytics:
http://g.raphaeljs.com
[3] https://github.com/mbostock/d3/wiki/Gallery
[4] http://www.analog.cx


___
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

[Florian Fuchs]

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@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@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] GSoC

[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] Browser ID integration with Mailman

[Florian Fuchs]

Hi,

 Now, I think we can get notifications pushed from the core to the ui if we
 wanted, assuming the ui had some service to notify.  See my previous message
 on events.

Awesome! So the wui would implement a simple REST API for the core to talk to. 
Ideally it should be possible to register more than one web ui (the official 
ui might not be the only application using the Mailman API), so multiple 
parties can be notified of changes. 
Also, we should probably think about how fine-grained those 
invalidate-notifications can be. It's probably not necessary to invalidate 
the whole cache every time something changes in the core. 

 There are upsides and downsides to this.  For example, do we want to keep the
 logic for authorization in the web ui?  That would mean if you integrate the
 core with your own custom web ui, then it wouldn't gain any of the benefit of
 the authorization logic in the Django app.  OTOH, that might be just what you
 want, and I can imagine a site like Launchpad would prefer that, since it has
 its own user model.

I wonder what the main use cases are for custom web uis. My guess is that many 
ui-creators might not build the whole thing anew, but create smaller 
applications for single tasks like (un)subscribing to lists etc. In larger 
integration scenarios, auth might be taken care of at some other stage (a 
company intranet for instance or a content management system). 

 Note too that I will be giving a talk on MM3 at Pycon, but fortunately I only
 have to fill 30m. :)
 
I know - I'll definitely be there! (Always wanted to know what this MM3 thing 
is and what it can do! ;-)
 
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] Browser ID integration with Mailman

[Florian Fuchs]

 
On Wednesday, February 22, 2012 07:49 CET, Stephen J. Turnbull 
step...@xemacs.org wrote: 
 
 Florian Fuchs writes:
 
   Agreed. Django's User model most definitely covers all our
   needs.
 
 What version of Django's User model are you using?  The vanilla User
 is actually rather limited.  Or do you mean as augmented by
 UserProfiles?  If the latter, do you have a specific schema for the
 Profile in mind, or are you just referring to its flexibility?

By User model I didn't mean the actual vanilla User model (sorry for not 
being precise). 
I meant its flexibility and that it can be easily enhanced. Also how it's 
automatically added to the request object and accessible from the templates 
etc. 

 
   The thing I am not sure about is: What kind of user info
   ends up in the core DB and what should be stored in the web ui
   db. In theory we don't need any kind of permanent storage in the
   web ui,
 
 We do, I think.  I think the core DB should be constant across
 Mailman installations, and restricted to fields useful in forum
 administration (ie, not restricted to mailing lists, although that
 will be the main purpose of Mailman 3 at its initial release).  The
 web UI DB storage would be optional and flexible.  But all fields and
 tables available to the web UI should be accessed by the same APIs in
 developing an instance of the web UI.
 
 Also, some fields of the core DB may be provided by a third party in
 vegetative state (eg, a personnel department).  We may want to allow
 the web UI to augment, edit, or override some of those fields in
 presentation.

Good point.

 
   But this means we'd have two different data sources since the web
   ui should not access the core db directly.
 
 Yes, the core DB and the web UI's persistent storage would be
 different.  But clients of the web UI's API need not know that, or do
 they?

If they become aware of that, something probably went wrong... ;-)

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] GSOC 12

[Florian Fuchs]

Hi Jagannathan, 

if the Error is TemplateDoesNotExist, the first thing to check would be: Does 
the relevant file exist and does the user starting the server have the 
necessary rights to access it?

In your case that would be the following file:

folder-where-mailmanweb-lives/mailmanweb/src/mailman_django/templates/mailman-django/lists/index.html
 
Any luck?

Florian


 
On Monday, February 20, 2012 11:50 CET, Jagannathan Tiruvallur Eachambadi 
jagannatha...@gmail.com wrote: 
 
 Sorry, the error is TemplateDoesNotExist. I forgot to start the mailman
 runner. This is the error I am getting : http://dpaste.com/705614/
 
 On Mon, Feb 20, 2012 at 4:10 PM, Jagannathan Tiruvallur Eachambadi 
 jagannatha...@gmail.com wrote:
 
 
  hi all,
 
   I am currently doing my first year of under-graduation in NIT-Trichy.
  I was reading the GSOC 12 getting started page and I am unable to to get
  the Django server working. I get ERNO 111 , I tried shutting down apache in
  my computer. But that did not solve the problem. I get the following error,
  http://dpaste.com/705607/ .
 
  On Sun, Feb 19, 2012 at 4:30 PM, 
  mailman-developers-requ...@python.orgwrote:
 
  Send Mailman-Developers mailing list submissions to
 mailman-developers@python.org
 
  To subscribe or unsubscribe via the World Wide Web, visit
 http://mail.python.org/mailman/listinfo/mailman-developers
  or, via email, send a message with subject or body 'help' to
 mailman-developers-requ...@python.org
 
  You can reach the person managing the list at
 mailman-developers-ow...@python.org
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of Mailman-Developers digest...
 
 
  Today's Topics:
 
1. Re: Probe messages should not sentPrecedenceheader (Mark
  Sapiro)
2. Re: Probe messages should not sentPrecedenceheader (Aamir
  Khan)
3. Re: Probe messages should not sentPrecedenceheader (Mark
  Sapiro)
 
 
  --
 
  Message: 1
  Date: Sat, 18 Feb 2012 09:22:53 -0800
  From: Mark Sapiro m...@msapiro.net
  To: Aamir Khan syst3m.w...@gmail.com
  Cc: Mailman-Developers@python.org
  Subject: Re: [Mailman-Developers] Probe messages should not sent
 Precedenceheader
  Message-ID: PC195201202180922530437aace67aa@MSAPIRO
  Content-Type: text/plain; charset=iso-8859-1
 
  Aamir Khan wrote:
 
  I guess in MM3, there is no function as sendNextNotification(), because i
  used command, grep sendNextNotification() -r * and the result was only
  file 'src/mailman/bin/disabled.py'.
 
 
  Which means that bin/disabled.py won't work because it hasn't been
  fully converted from 2.1 yet. It should be using the send_probe()
  function instead of sendNextNotification().
 
 
  There is a file 'src/mailman/email/messages.py', in which
  UserNotification() class is defined. It has a send function, which sets
  the
  precedence header.
  
  In file 'src/mailman/app/bouces.py', I guess the probe messages are sent
  directly using send() function of UserNotification() class. I think that
  from line 211 to 228, probe message is used to send VERP probe. But
  then, i
  am not able to find out the place from where probe message is sent after
  disabling of the address because of over bouncing.
 
 
  There should be two places. bin/disabled.py should be calling
  send_probe() instead of the non-existent sendNextNotification() list
  method.
 
  Also, send_probe() should be called when delivery is initially disabled
  as a result of a call to IBounceProcessor(), but I am unable to follow
  how this works or even if it is implemented yet at least in part
  because I haven't yet learned anything about how things like
  zope.component.getUtility() work.
 
 
  I have tried to make some changes to code and pushed it to my local
  branch
  [1]. Ran through all the tests, and none of them failed. Is there any way
  to run through a subset of test rather than running them using 'bin/test'
  command.
  
  Comments, feedback required on patch.
  
  
  [1] =
  http://bazaar.launchpad.net/~syst3mw0rm/mailman/precedence/revision/7080
 
 
  The patch itself looks good except for style. We normally don't put
  whitespace around the = in keyword=value arguments in definitions and
  calls. PEP 8 http://www.python.org/dev/peps/pep-0008/ says Don't
  use spaces around the '=' sign when used to indicate a keyword
  argument or a default parameter value.
 
  --
  Mark Sapiro m...@msapiro.netThe highway is for gamblers,
  San Francisco Bay Area, Californiabetter use your sense - B. Dylan
 
 
 
  --
 
  Message: 2
  Date: Sat, 18 Feb 2012 23:16:37 +0530
  From: Aamir Khan syst3m.w...@gmail.com
  To: Mark Sapiro m...@msapiro.net
  Cc: Mailman-Developers@python.org
  Subject: Re: [Mailman-Developers] Probe messages should not sent
 Precedenceheader
  Message-ID:
 
  

Re: [Mailman-Developers] Error while setting up mailman UI

[Florian Fuchs]

Hi,
 
On Friday, February 17, 2012 17:13 CET, Aamir Khan syst3m.w...@gmail.com 
wrote: 
 
 Hi,
 
 I tried to create a virtualEnv in python and start the installation from
 scratch. But i a still getting the errors. Screenshot is attached. I also
 tried running the tests and many tests failed. One of the dominant error
 was,
 
 ImproperlyConfigured: Module mailman_django.context_processors does not
 define a lists_of_domain callable request processor

You can find an up to date (and tested) version of the settings.py in

lp:~flo-fuchs/mailmanweb/django_dev_setup

If you update to the latest version it *should* work now.

Cheers
Florian


 
 
 On Fri, Feb 17, 2012 at 5:48 AM, Florian Fuchs f...@state-of-mind.de wrote:
 
  Hi,
 
  On Friday, February 17, 2012 00:40 CET, Aamir Khan syst3m.w...@gmail.com
  wrote:
 
REST_SERVER = 'http://localhost:8001'
   
   I guess that should be,
  
   REST_SERVER = 'http://localhost:8000'  because the django app runs on
  8000
   port.
 
  Yep, the Django dev server runs on port 8000. But the REST_SERVER setting
  refers to the Mailman API which usually runs on port 8001. Did you try
  that, too?
  Also, did you start mailman by running 'bin/mailman start' from your
  mailman directory?
 
  If that doesn't work, you could try and run the wui tests:
 
  1) stop mailman ('bin/mailman stop' from inside your mailman dir)
  2) set MAILMAN_TEST_BINDIR in your settings.py (full path to:
  .../mailman/bin)
  3) from the folder where the settings.py lives run: 'python manage.py test'
 
  If the tests run through you know the web ui is setup correctly and can
  talk to the mailman REST API.
  If they don't the output should give us a hint where the problem might
  be...
 
  I hope that helps...
 
  Florian
 
 
  
   When, changing it to above line, the URL 'http://localhost:8000' takes
   forever to load but at least no error popped out.
  
   
where it probably now says:
   
REST_SERVER = 'localhost:8001'
   
(missing url scheme...)
   
Sorry for not having updated the settings-branch on launchpad
  earlier...
:-/
   
Is this solving the problem?
   
(If you have any further questions please don't hesitate to contact me
  via
mail or on irc - florianf on freenode.)
   
Cheers
Florian
   
   
   
On Thursday, February 16, 2012 17:54 CET, Aamir Khan 
syst3m.w...@gmail.com wrote:
   
 Hi,

 I am getting error while trying to setup mailman UI by following the
guide
 of setting up mailman web UI running[0].

 I have attached the screenshot of the same. Any help will be
  appreciated.

 [0] =

   
  http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running




 --
 Aamir Khan | 3rd Year  | Computer Science  Engineering | IIT Roorkee
   
   
   
   
   
___
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/syst3m.w0rm%40gmail.com
   
Security Policy: http://wiki.list.org/x/QIA9
   
  
  
  
   --
   Aamir Khan | 3rd Year  | Computer Science  Engineering | IIT Roorkee
 
 
 
 
 
 
 
 
 -- 
 Aamir Khan | 3rd Year  | Computer Science  Engineering | IIT Roorkee
 
 
 
 

___
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] Browser ID integration with Mailman

[Florian Fuchs]

On Friday, February 17, 2012 20:41 CET, Florian Fuchs f...@state-of-mind.de 
wrote: 
 
 [1] https://github.com/lloyd/myfavoritebeer.org/
 [2] https://github.com/mozilla/django-browserid
 [3] https://github.com/mozilla/django-browserid

Sorry, I posted the second link twice. That should be:

https://github.com/omab/django-social-auth

Florian



 
 
  
  -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/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/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] Error while setting up mailman UI

[Florian Fuchs]

Hi Aamir,

thanks for being interested in MM3 and its web ui!

A small change I recently made to the default settings seems to be the cause of 
the error message:
In line 32 of your settings.py it should say: 

REST_SERVER = 'http://localhost:8001' 

where it probably now says:

REST_SERVER = 'localhost:8001'

(missing url scheme...)

Sorry for not having updated the settings-branch on launchpad earlier... :-/

Is this solving the problem?

(If you have any further questions please don't hesitate to contact me via mail 
or on irc - florianf on freenode.)

Cheers 
Florian


 
On Thursday, February 16, 2012 17:54 CET, Aamir Khan syst3m.w...@gmail.com 
wrote: 
 
 Hi,
 
 I am getting error while trying to setup mailman UI by following the guide
 of setting up mailman web UI running[0].
 
 I have attached the screenshot of the same. Any help will be appreciated.
 
 [0] =
 http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
 
 
 
 
 -- 
 Aamir Khan | 3rd Year  | Computer Science  Engineering | IIT Roorkee
 
 
 
 

___
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] feature request: one-click setting to preserve DKIM

[Florian Fuchs]

Hi, 

 users will balk at having the subject line tags removed, and many list 
 owners will balk at having unsubscribe footers removed, 

Agreed. OTOH, if this were yet another setting, it would be the list owner's 
decision to use it or not.

 That said, we've talked a lot about having simplified interfaces for 
 quick list administration and interfaces designed for specific purpose 
 lists. It seems like this might fit in nicely with some of those ideas, 
 so I'm definitely not adverse to keeping it in mind as an interface 
 option if there's evidence that this would be useful to enough list owners.

I also think it's worth considering. For instance, those settings could be part 
of one or more DKIM compatible list templates. But even if we bundle this 
inside a template it will probably still cause a bit of confusion (how many 
people will know what the label 'DKIM compatible' means?). 

Another idea: We could still let the person installing the web-ui decide if 
they want to make those options available. Maybe by means of an additional 
django app that adds this functionality to the settings.

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] GHC11 open source day

[Florian Fuchs]

Hi, 
 
 (Thanks 
 again for letting us abuse your server, Florian!).  
You're very welcome! BTW: Thanks to Patrick Koetter for providing us with a 
virtual machine to play around with. 

 I've got a huge pile of notes and a suitcase filled with big paper 
 prototypes, like the one 
 Mel's working on in this photo:
 https://photos-2.dropbox.com/i/l/tGZOpFHyUZYWdP8qQIWC3bCtfwQ7vqHMrwqhz8tGWC4/9183906/1321347600/f75f406/DSC_6385.JPG#20
 
 Over the next week or so I'll be digitizing what we produced in the form 
 of photos, ui mockups and notes on the wiki.
That sounds (and looks) fantastic! I am SO looking forward to see the results.

 If anyone's interested in helping with the UI work, I could use some 
 help!  This is a great place to start if you've always wanted to help 
 but weren't sure what to do or were worried your python skills weren't 
 up to snuff.  I should have the photos of the paper prototypes up 
 Monday evening (I'm on US Mountain time) and I'd love some help 
 translating the photos into UI mockups (either on the wiki or 
 semi-functional HTML/JavaScript prototypes) to start.
I have streamlined the installation process for the web ui a bit and am in the 
process of setting up something like a 5 Minute Guide to Getting the Web UI 
Running page in the wiki. I hope to post the link here within the next hour or 
so...

Cheers
Florian



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