Since I now treat every gathering of hackers as an excuse to get people
to tell me things about Mailman, I was chatting with folk at the GSoC
mentor summit and my friend V was telling me that she really likes
Listadmin as a nicer interface to Mailman:
http://freecode.com/projects/listadmin
Seems like something I might have to look at and learn some lessons from
before we're done with postorius dev.
Anyhow, it got me thinking: does anyone here use any other add-ons that
they think I should know about? :) I used to have a set of greasemonkey
scripts for my own lists, and I'll bet I'm not the only one.
Terri
Isn't the visibility of the list members a per_list policy setting?
In any case, we will need to have list administrators (who are not the superuser) be able to see the membership on their list.
I think that Postorius will require a better model for roles.
Richard
On Oct 25, 2012, at 3:19 AM, Florian Fuchs <flo.fuchs(a)gmail.com> wrote:
> Review: Approve
>
> Hi George,
>
> thank you for your changes (and the bug reports)! I have just merged them to the trunk. I only made some very small changes and additions (adjusted the docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I also made the user list and details only available to superusers (I don't think every user should be able to see who else is there...).
Back in 2005, while working at an OS X Server-based organization, I wrote a bash + python script pair that extracted students/staff/faculty from a database to populate mailman lists, where many members were subscribed to various lists in nomail mode, using add_member's "-e" flag. The system worked very well.
Later, we dropped OS X Server and moved to Linux, and I was surprised to find that my script no longer worked. Only then did I realize that "-e" for "nomail" was an Apple customization that never found its way into the standard Mailman distribution. I solved the problem by copying the Apple-provided add_members to my Linux systems and changing the python shebang at the top.
These days, I find myself still doing the same thing on the cPanel-based systems I run, which means my systems break each time cPanel updates Mailman, and that I now run a very old version of add_members. Every organization I've worked for has had this need to batch-add people in nomail mode, which makes it really surprising to me that the standard distribution still doesn't support the option (I can't possibly be the only admin with this need!)
Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included?
Thanks,
Scot
When a handler raises Errors.RejectMessage to reject an incoming post,
nothing is logged. I have filed
<https://bugs.launchpad.net/mailman/+bug/1068837> in preparation for
addressing this.
My question is what to log. Currently, IncomingRunner logs automatic
discards with the message 'Message discarded, msgid: %s'. This is a
bit cryptic. I think it would be good to have the list name in this
message, but I have never changed it as that could be disruptive. It
would also be possible to log which handler raised the exception, but
again, that could be disruptive.
With a new message for rejects, disruption is not much of an issue as
existing log analyzers would presumably not recognize the message and
skip it, which is no different from no message, or report the raw
message.
The question is whether it is a good thing to log the error message
that accompanies the exception. This can be quite verbose as the error
message can be the list's member_moderation_notice or
nonmember_rejection_notice, but if only the handler name is logged, it
doesn't distinguish between a non-member reject and a moderated member
reject.
Does anyone have an opinion on this?
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
[Redirecting part of this discussion from mailman-users to
mailman-developers. Mark does a great job of explaining the gory details of
the queue runners.]
On Oct 16, 2012, at 09:23 PM, Mark Sapiro wrote:
>First of all, The actual physical size of the queue directory impacts
>processing. Every time an entry is added to the queue, and every time
>a .pck file is renamed to .bak, the entire physical directory must be
>searched to ensure this isn't a duplicate name. Depending on OS
>settings, cache sizes and the physical directory size, this may
>actually involve multiple disk reads each time. Thus, if the
>qfiles/out/ directory has grown large because 8000+ messages were
>added to the queue when the runner couldn't handle them (and there may
>have been more in the retry/ queue because of SMTP failures), it would
>benefit from shrinking. This is accomplished by moving (mv) or
>renaming the queue directory itself aside, not just its contents and
>then letting the runner recreate it when it starts. Then, if
>necessary, move messages back a few at a time so the directory doesn't
>grow large again.
I'd like to begin to explore ways to make this automatically more manageable,
so that when problems occur (e.g. upstream SMTPd not responding or slow),
Mailman can recognize and response more efficiently to the problem.
The first question to ask is whether this mostly affects the outgoing queue,
or whether other queues *in practice* can suffer the same overloading? I
suspect that the incoming queue could get filled quickly if Mailman is slow to
handling an onslaught of new messages. My sense is that in general, it's the
outgoing queue that gives people the most problems though.
The switchboard in Mailman 3 is largely the same as in Mailman 2 (modulo
updating the code to more modern Pythons).
Before describing my own thoughts, I'd like to open it up and get a sense of
your experiences, and strategies you think might help manage big queues.
Cheers,
-Barry
A very quick report:
We had our post-GHC12 hackathon today and I think we were wildly
successful. I didn't sit down and count, but we had around 15 women,
most new contributors, hacking on Postorius/Mailman today. We stomped on
a bunch of the specially-marked bugs, and just as vitally, we had a
bunch of folk go through decent first-pass usability testing of the
Postorius interface with Robin (who is an experienced UI person from
Google) and file bugs for the missing bits that seem most essential for
the Postorius release. Sometimes we also filed fixes for the bugs that
were tractable in the time we had!
Because we were on limited time, I've just got a pile of contributions
tarballed up on our dev vm (and backed up elsewhere), and I got everyone
who fixed a bug to comment on it on Launchpad so we can send out the
appropriate copyright forms. I'll be marking those bugs as fixed once
I get home (I need to pack and sleep now) and sometime thereafter
(probably next weekend) I'll separate out the code to merge requests and
triage the rest of the new bugs so we can start work on those.
I think people had a lot of fun seeing their code go live on our test
server and watching their bugs get fixed, and I think we've got a few
contributors who'll be interested in doing more (and maybe, once I
wrangle the travel funds, coming to pycon!). I'm so very excited! :)
Terri