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! ------------------------------------------------------ Mailman-Users mailing list [email protected] https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
