For those of you who don't keep track, our GSoC students officially
started coding on May 21st, so today marks their second week (except for
George, who started early). I hope you've all gotten settled in and
are getting down to work!
I've got two things I need from all of the GSoC students:
1. By tomorrow, you need to write a status report telling us all about
your first week (see more detail below)
2. I want ALL of you to make some sort of commit or merge request to the
Mailman/Postorius/Hyperkitty repositories by June 4th, so get ready to
This first commit to the repository doesn't have to be a big deal. If
you don't have any code yet, it's ok if you just check in some directory
structure you'll be using later and files with nothing but comments
explaining how they'll be used later. The idea is to make sure all of
us know how to get your code into the repositories in a useful way,
including making sure we all know where to find the appropriate knobs in
The status report also doesn't have to be huge, but here's what I'd like
1. What did you do in the past week? (May 21-28th)
* Include links to any code/documentation you've written. If it's
not checked in somewhere yet, check it in!
2. What do you plan to do next week? (May 28-June 4)
* This can be a bit sketchy, but feel free to dream big!
3. What, if anything, caused you trouble this week?
4. Do you have any questions that came up? (And these can be things
like "why is this directory here?" or "why is it called Postorius,
anyhow?" as well as stuff relevant to exactly what you're working on.)
5. Do you have any other important upcoming plans? (This includes
reminding us when you have exams coming up, or you have to go to your
sister's wedding, or other things that just don't fit under "next week")
Expect to be doing weekly reports for most of the summer -- it's an easy
way to help give all the mentors and other developers an idea of where
you are and when you might need help.
Starting next week I may start sending private reminders, but I figured
I'd start by telling the whole list so they know to be prepared for your
code commits and to expect status reports starting tomorrow.
On 05/24/2012 07:12 PM, Jeff Marshall wrote:
> I would recommend displaying only the subject line like you are now
> and having a button that displays the body in a pop-up modal.
There should be some kind of fallback for non-JS users, though. Since
the Postorius base template detects JS, I suggest a simplfied CSS-only
version for non-JS-clients (possibly depending on the :hover or :active
state of the button) and the pop-up modal for JS-enabled ones.
How do you think that this should work?
Should we always display at least a part of the message as a part of the list? Or should we display only the subject and have a linkage to the body of the message, perhaps as a pop up window?
On May 24, 2012, at 11:50 AM, Jeff Marshall wrote:
> Public bug reported:
> The Held Messages page on Postorius only shows the subject line of the
> messages. It seems like the body of the message will also be important
> for reviewing the held message.
On 05/22/2012 07:49 PM, Jeff Marshall wrote:
> Hey everybody. I've been playing with 3.0.0b1 and Postorius. I have
> some questions as well as some initial feedback. I am assuming many
> of these are known issues or works-in-progress so I apologize ahead of
> * How do I add another person as an administrator to either a single
> list or to my full mailman installation? I don't see this in either
> Postorius or the command line tools.
As far as Postorius is concerned, this is indeed work in progress.
At the moment you can add new superusers (for the full Postorius
installation) via the command line from the dev_setup directory:
$ python manage.py createsuperuser
> * The BrowserID system on Postorius logs me out all the time, even
> after just a few page views. I'm constantly having to hit the sign-in
> button again. If I am trying to perform an administrative function I
> have to do it very quickly after signing in or else I'm logged out
> again. (Mac OS X, Chrome).
My first guess was that it's a problem with browser privacy settings. So
I tried to reproduce the problem with different cookie-settings -
session-only, no 3rd party cookies, all cookies allowed. Still
everything worked fine. I guess you do allow at least session-based
cookies (otherwise you wouldn't have been able to log in in the first
Is it possible that you got thrown out after you got an error? If so,
could you post the exception type displayed in the dump?
Does that happen only with browserid or also when you're logged-in with
the superuser account created on syncdb??
> * The Held Messages page on Postorius only shows me the subject line
> of the messages. It seems like the body of the message will also be
> important for reviewing the held message.
+1 ...only I think the msg body currently isn't exposed by the MM API
(@Barry, can you confirm that?), in which case we would need two bug
reports: One for mailman (expose body of held messages) and one for
Postorius (show held msg body).
> * I get an error dump whenever I accept a held message on Postorius.
> The message goes through, though.
> Exception Type: AttributeError
> Exception Value:
> 'module' object has no attribute 'successful'
> Exception Location:
> /home/marshman/mailman/postorius/src/postorius/views.py in
> accept_held_message, line 405
This is a bug. Feel free to file a bug report on LP. Otherwise I will... ;-)
> * Postorius doesn't seem to have confirmation messages after changing
> a setting or adding a subscriber. It leaves me uncertain whether my
> change or subscriber addition went through.
+1 for confirmation messages on settings changes etc.
But you should see a confirmation message after
subscribing/unsubscribing (displayed just below the page header).
> * Postorius could use a page showing the list members.
> * Is there a plan for exposing some list traffic stats on the Mailman
> API and on Postorius? It would be handy to see # of messages received
> today, etc, especially at this stage when I'm trying to figure out
> what is working or not.
Like Barry said: Luckily, there's a GSOC student working on metrics.
> * It might be handy in the Postorius docs to mention how to run a
> Django server on a public url; I hadn't used Django before so I was
> spinning my wheels for a bit until I dug this up:
> $ python manage.py runserver 0.0.0.0:8000
You should use the django dev server only for testing.
Writing a tutorial on how to run Postorius using Apache has been on my
todo list for a while. There are a number of tutorials out there on
Django/Apache though... (But I should still finally write that thing... ;-)
> I'm happy to file tickets on Launchpad but I didn't want to do so
> until I understood what is already in progress.
There's no reason why you shouldn't. And thanks a lot for your feedback!
On May 19, 2012, at 5:12 PM, Florian Fuchs wrote:
> Personally, I only delete branches only if I'm really sure I won't work
> on them any longer.
> I'm also pretty sure that when you delete a branch
> that has been merged into a project, it's still accessible from the
> revision timeline and the bug report, even if it's no longer visible in
> your profile's branch list. So once it has been merged into another
> branch there's no way of removing it from LP.
My interest in deleting a branch is to clean the external namespace so that users are not wasting their time examining branches which are not currently useful.
It appears that Launchpad handles this by setting the branch status to "merged".
As a result, I don't need to do anything.
> I use git a little more often then Bazaar, but I can't say that I am
> clearly in favor of one of them. I guess I'm just happy whenever I don't
> have to use SVN any more. ;-)
My experience goes back to RCS. CVS was an improvement on that. Today's version control systems are much better. My only complaint is that there are too many of them :)
My preference for git stems largely from the lack of decent gui tools for bzr on Mac OSX. That, plus the fact that I run a git-based infrastructure and most of the other projects in which I participate use git, makes it an easy choice for me.
> I think the workflow used in Launchpad is not necessarily the only way
> to use Bazaar. However, I can't say that I have really fully groked the
> launchpad way, but here's how I understood it:
> Every project has an owner (a person or group, "Mailman Coders" in our
> case). Changes to the trunk can only be made by owners, which is why
> nobody else's names ever appear in the revision history.
What a waste of display space :)
> The way launchpad credits the work of "non-owner" contributers is by stating the
> merges and bug fixes in the revision history the way it just happened
> with your branch.
> So there's nothing wrong with the way you did it. Just create a new
> branch with the changes and then do a merge proposal. You *could* link
> the branch to the bug report yourself, just to make sure I don't forget
> that before merging it in.
I'll try to do so for the next submission. As you note, there are many ways to use a particular tool. "Learning the culture" is part of the contribution task.
> You see, those "non-owner" contributions are buried a bit deeply inside
> the revision history. And I guess that's why Barry suggested to add a
> more obvious "contributed by ..." message to every commit that involves
> the work of a non-owner.
I prefer the more explicit attribution of git because it makes it much easier to determine "blame". Not that I care about kudos, points, or such, but because I often want to know more about the rationale behind some particular change. (The documentation rarely is adequate in explaining rationale -- and we are all "guilty" in that respect) To do so, I need to know the author
> But, as I said: That's just how I understood the LP workflow. I'm sure
> there are still things I've missed...
My workflow pattern is to create short-lived branches for each bug, Once the bug is closed and merged into trunk, the branch is effectively "dead". Launchpad seems to handle this adequately.
>> I'm working on some new underlying base.html files. Fortunately, Django lets me place them directly in my website directory and the template loader then overrides your version. When they are ready for, and get merged into the trunk, I can easily revert to the vendor version.
>> I think that we should create an otherwise empty "themes" app and place the various templates within that namespace rather than directly in the postorius namespace. What is your opinion?
> I guess it would be a bit confusing to have the default templates in a
> completely different app (at least for people who use django regularly).
> My feeling is that it's kind of expected for django users to have a
> default theme delivered as part of the actual app package. So I would
> prefer to deliver the theme as part of postorius as well.
> As far as alternative themes are concerned I have seen some cases where
> additional themes were distributed as separate apps
As an "installer" mechanism, this seems just fine. And I agree that a default theme should be delivered as a part of the postorius package.
However, I am concerned that your implementation exposes "/postorius/" in the URLs and in the template names for the themes.
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. 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.
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. This does not imply that we cannot package one, or more, themes in the postorius app.
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.
On May 22, 2012, at 10:49 AM, Jeff Marshall wrote:
>Hey everybody. I've been playing with 3.0.0b1 and Postorius. I have
>some questions as well as some initial feedback. I am assuming many
>of these are known issues or works-in-progress so I apologize ahead of
Glad you're taking a look Jeff. I'll answer questions about the core and
leave Postorius to the web guys. :)
>* How do I add another person as an administrator to either a single
>list or to my full mailman installation? I don't see this in either
>Postorius or the command line tools.
This is not exposed in the cli right now. It's certainly not hard to do from
the internal API, and in fact would be fairly easily to write as a 'withlist'
The closes thing right now is the 'members' subcommand, which takes an --add
switch. This is still pretty dumb though because it's only capable of adding
regular members to a single list.
What kind of cli would you want to see? I'm not sure whether this
functionality should go in the 'members' subcommand, or a separate
subcommand. I'm also not frankly certain that 'members --add' is a very good
cli. (Possibly, 'members' should morph into a read-only command, with a
separate command for updating.)
>* How do I enabling public archiving? I see the archive mentions in
>the config files but I'm not finding it clear how to flip it on.
Right now, it's a little convoluted. (I'm still trying to get the schema
migration branch working, which could change some of this.) The mailman.cfg
file is used only to globally enable, disable, or define archivers available
to Mailman. Each mailing list itself then has two variables which essentially
expose three states:
* mlist.archive (bool) - whether the mailing list archives messages at all
* mlist.archive_private (bool) - whether archives for the list are public or
Once the schema migration branch lands, this will be one variable
mlist.archive_policy with an enum value, something like ArchivePolicy.never,
Now, what actually happens with these values is currently left up to the
individual archivers, with the mail-archive archiver being the only one that
looks at mlist.archive_private. If this value is true, it will simply ignore
any messages handed to it. None of the other archivers currently do anything
with this value.
mlist.archive *is* used globally in a few places. It informs whether the
List-Archive and Archived-At headers get added, but more importantly, if this
value is false, the message will not even get enqueued to the archive runner.
>* Is there a plan for exposing some list traffic stats on the Mailman
>API and on Postorius? It would be handy to see # of messages received
>today, etc, especially at this stage when I'm trying to figure out
>what is working or not.
There is a summer of code project addressing this.
>I'm happy to file tickets on Launchpad but I didn't want to do so
>until I understood what is already in progress.
That's the state of affairs as regards to the core. Do feel free to file bugs
on the cli for adding owners and moderators. Keep in mind that some bits of
the archiver infrastructure will change with the schema migration.
Please tag bugs with 'mailman3' so they show up on my radar. :)
Hey everybody. I've been playing with 3.0.0b1 and Postorius. I have
some questions as well as some initial feedback. I am assuming many
of these are known issues or works-in-progress so I apologize ahead of
* How do I add another person as an administrator to either a single
list or to my full mailman installation? I don't see this in either
Postorius or the command line tools.
* How do I enabling public archiving? I see the archive mentions in
the config files but I'm not finding it clear how to flip it on.
* The BrowserID system on Postorius logs me out all the time, even
after just a few page views. I'm constantly having to hit the sign-in
button again. If I am trying to perform an administrative function I
have to do it very quickly after signing in or else I'm logged out
again. (Mac OS X, Chrome).
* The Held Messages page on Postorius only shows me the subject line
of the messages. It seems like the body of the message will also be
important for reviewing the held message.
* I get an error dump whenever I accept a held message on Postorius.
The message goes through, though.
Exception Type: AttributeError
'module' object has no attribute 'successful'
accept_held_message, line 405
* Postorius doesn't seem to have confirmation messages after changing
a setting or adding a subscriber. It leaves me uncertain whether my
change or subscriber addition went through.
* Postorius could use a page showing the list members.
* Is there a plan for exposing some list traffic stats on the Mailman
API and on Postorius? It would be handy to see # of messages received
today, etc, especially at this stage when I'm trying to figure out
what is working or not.
* It might be handy in the Postorius docs to mention how to run a
Django server on a public url; I hadn't used Django before so I was
spinning my wheels for a bit until I dug this up:
$ python manage.py runserver 0.0.0.0:8000
* While attempting to build the docs I get this:
$ python setup.py build_sphinx
line 216, in __init__
exec code in config
File "/home/marshman/mailman/mailman-3.0.0b1/conf.py", line 54,
from mailman.version import VERSION
ImportError: No module named version
I'm happy to file tickets on Launchpad but I didn't want to do so
until I understood what is already in progress.
The Mail Archive
-----BEGIN PGP SIGNED MESSAGE-----
I am happy to announce the first release candidate for Mailman 2.1.15.
Python 2.4 is the minimum supported, but Python 2.6 is recommended.
This release should work with Python 2.7, but has not been tested with
This release includes minor security enhancements, new features and
bug fixes. See the Changelog at
<https://launchpad.net/mailman/2.1/2.1.15rc1> for more details.
Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.
For more information, please see:
Mailman 2.1.15rc1 can be downloaded from
It is anticipated that the 2.1.15 final release will be on or about
June 13. Bugs found between now and then will be fixed if possible,
but I hope that most if not all changes between now and June 13 will
be i18n updates. Please send any updates to the templates and/or
message catalogs in the 2.1.15rc1 release directly to me no later than
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
-----END PGP SIGNATURE-----
The following document is the lowest level of my design concept. You
may also read it in my blog . Of course, comments are very welcome.
In order to store statistical data, the app will use some Django models:
This model represents an author of the mailing list. It mostly keeps
track of the number of postings and number of threads started. It has
the following fields:
- authorid – IntegerField
- authormail – CharField
- totalmails – IntegerField
- totalthreads – IntegerField
- firstmsgdate – DateTimeField
- lastmsgdate – DateTimeField
This model counts the total number of postings and threads started.
- totalmails – IntegerField
- totalthreads – IntegerField
This model associates the author and the mailing list with each month.
- author – ForeignKey
- month – CharField
- postscount – IntegerField
- threadscount – IntegerField
- mailinglist – Boolean (if this is true it corresponds to the whole
This model is similar to month. It has a year field instead of a month field.
To display the metrics the Django template system will be used. To
output the charts i will create some custom tags. The three following
views will be used:
- General page – On top, there will be general metrics about total
authors, total mails and total threads and below three charts (AJAX
based) that represent number of posts per author, number of threads
per author and mailing list’s yearly usage. Even below there will be a
number of charts (equal to the number of years of list’s existence)
that output monthly usage. At the end, there will be tabular data
representing the authors of the mailing list along with their number
of posts, number of threads started and the date of their last post.
The user will be able to order the tabular data (alphabetically,
ascending/descending on number of posts, number of threads, date of
last message) by clicking on the table’s headings (Mail, Mails Sent,
Threads Started, Last Message).
- Author page – Each user will have his own page with his own metrics.
On top, there will be the email of the author, number of posts, number
of threads started and the dates of first and last message. Below
there will be monthly usage charts for each year the user is
subscribed to the mailing list.
Django Admin page – A ‘Generate’ button will be added to the Django admin page.
The Django app should handle the following configuration parameters:
- Host – Message store data host
- Port – Message store data port
- Masking – A multi-state variable (None, abbreviated, full) for
masking email addresses at the results (we don’t want the emails to be
Interface to the Mailman core
- Metrics class – When a new post is sent, the Metrics class will
receive it through the IArchiver interface. The Posts field of the
Mailing List model (as well as the the related rows on the Month and
Year models) will increase by one. If the author’s email is not in the
database, it will query the mailman core database with the email, grab
the author’s id and a new Author row will be created. Otherwise if the
author is already in the database, the Posts field and the two foreign
fields (Month and Year) will increase by one
- Generate class – When the ‘Generate’ button on the Admin page is pressed:
* The Django models will be initialized (the metrics will go back to
zero). A progress bar will inform the administrator that the operation
is being processed.
* All the messages of the archive will be parsed by performing a
direct Python call to the IArchiver. Another instance to the IArchiver
will grab any mails sent while the parsing is going on.
* The metrics will be generated from scratch.
* The administrator will be informed with a success message when the
process is over.
Subscription notification mail body is also distorted sometimes: I just
received one for a new subscriber who used a diacritic in his name.
There is '?' (ASCII 0x3F) instead of the character with diacritic.
OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0