[Mailman-Users] Diagnosing command failures

[Stephen J. Turnbull]

Gary Merrill writes:

 > I know the kinds of problems you guys are facing -- although you
 > should be somewhat grateful that you aren't dealing with the FDA,
 > insurance companies, gigantic healthcare organizations, the CDC,
 > and multiple pharma companies. :-)

I don't have to deal with them, but many of my thesis students study
exactly the set of problems you're referring to and I shudder at the
thought of trying to develop for that industry.

 > From my point of view, what would be ideal in managing a Mailman
 > list would be to have all the relevant data for the list in "my
 > space", and accessible to me so that on the rare occasions when
 > things don't work I could at least look for what is causing the
 > problem.

If you have specific requirements, it's actually very likely that they
would be implemented.  For example in another thread somebody was
cloning a list (ie, he wanted a configuration very similar to one he'd
created previously, but with all-new membership, and I casually asked
Mark if he had a script.  He didn't (then :-), but within 48 hours he
had already released a first version and the first upgrade.  Specific
need + fairly well-defined statement (but full spec not required) =
quick response.

But if you just say "all relevant", hey, we can turn the firehose on
you but I don't think you'll like that.  And experience shows that
we're not very good at guessing what *others* mean by "relevant".  We
know what *we* mean by "relevant" -- and have already implemented 99%
of it.

If it's newly collected data, it may take a while to percolate into
the release (and then longer again if you want a package from your
distribution).  But often the data is collected but not collated, and
a script could be written to do that work (several people have such
scripts, but they're often 3rd-party-software-specifc, eg, to a
particular MTA).  That can often be done in a day or seven.

 > I don't know your architecture or your constraints, and so I'm not
 > going to start pitching such ideas at you in the form of change
 > requests.

Speaking only for myself, I wish you would.  (Well, I do suspect the
other devs -- who write a lot more code than I do -- feel the same
way.)  We know the architecture, you know the (for values of "the" ==
"your" :-) requirements.  We can always WONTFIX them, which of course
is frustrating for you, and (here I'm sure I'm speaking for all
Mailman devs) we genuinely regret your frustration.  But if you don't
tell us, there's a very good chance we'll never hit on the idea.

Note that for mail flows, the architecture is extremely flexible.  We
have a *lot* of metadata attached to *each* message, and a pipeline of
"handlers" which use that data in various ways.  An optional enhanced
logging handler could easily be added "immediately" and per-list (for
folks who have access to the Mailman installation, of course).  I
don't think it's that easy in the web interface, but I could be wrong
(and it wouldn't be hard in a future version to install a hook for
user-installed handlers if some provision doesn't exist already).

 > Mailman is currently quite nicely satisfying the needs I have, and
 > I look forward to the next release.

Glad to hear that!