Brad Knowles said the following on 2006/09/01 01:24 AM: > This is the key point that was not coming across to me, at least not > until much later in the exchange. Speaking only for myself, I seriously > misunderstood what you were asking and why, which greatly colored my > responses.
My apologies, I could have been clearer. I did try and fork the thread with the inclusion of (devils advocate!) in the subject line. > I'm still not certain that we've given you the best answer to this > question, but I'm hoping that you'll be able to synthesize something > that you will then be able to contribute back to the community, and we > will hopefully be able to avoid these kinds of problems in the future -- > at least with respect to this one particular issue. I may not have what I was looking specifically, but I do have a clearer of how to approach things in future. I've had to edit context significantly for various reasons (brevity being one) but it comes down this. We've had a solution in place for 10 years that just works but doesn't offer us the functionality we need or clients want any more. I've been on mailman run lists for ~6 years and found the setup to be more useful and when the time came for a new server had to make a number of decisions based on skills available, difference in volumes of legitimate mail and spam today (compared to setup of ageing server from 96) and new things to be learnt using a different OS and architecture. A mistake appears to be the perception (prior to installation and initial use phase) that Mailman was Majordomo with a web-gui and archives. It's not. It's a different product and approach entirely. This realisation is hammered home in the implementation of Mailman -- but not easily visible when researching alternative solutions to the previous way we did things. Such a mistaken perception is echoed both up to management and down to users in selling the solution. You get approval, go ahead and implement and then there this "oops" moment and realisation you didn't have all the knowledge to begin with, and sold management and users a solution you just couldn't (at the time) anticipate certain problems with. So it's your head on the block and you either have to wing it or come up with an explanation that satisfies both users and management without too much trouble in the process. Just as an example, some list-owners have pending administrative request queues numbering in the hundreds already. No amount of prodding or pushing or assisting helps them just to complete a small and easy daily task. Feedback is "my prior list didn't bother me with stuff" or "Oh, I used to just ignore that stuff anyway". Horse --> water situation. Additionally in terms of the historical setup, things with majordomo were already highly customised to our needs, and when I came in I assumed/took-for-granted this was the default (old system has even worse documentation than anything else I've seen <chuckles>) and also assumed thing would be echoed in the Mailman setup. My mistake, but during the "ask around for suggestions" phase most of the feedback I got was Mailman orientated, like the move is just a casual change in clothes. It's not :-) Now despite my mixed positive/negative reactions to documentation and feedback from the list, and growing growing appreciation of why certain things were done a certain way, neither users or management have the time to sift through the same volume of information to reach a satisfactory conclusion. Instead you get a very offensive response due to resistance to change, or new variables. You see the following doesn't cut it in that situation: * but we can change it * we can modify the source if we need to * that's the way the developers chose to do it * the documentation was lacking In an environment where someone has to take responsibility for a situation, even if it's not their fault as such, providing the best answer to users or management can go two ways. Shift the blame, or fix the problem -- even if it means undoing the best practices suggested and letting users/management realise for themselves why it's a bad idea. But in some environments you just can't afford to do this. So far I've discovered that yes, most of the safe defaults are the best desired functionality. And that on a Debian/Exim setup it's best to install from source, and if using virtual domains to install a separate installation of mailman per domain. The additional overhead on the box isn't that much for ~20 domains. It might be for more than that though. I've also found the documentation to be scattered but where there is info that can be referenced, it's generally pretty good. Once we have a stable system that meets the needs of users and management I'll be happy to share the setup of how we've done it in our particular way along with some rationale behind the different decisions based both on what I've learnt on this list, and from user/management feedback. Obviously every installation is in a different environment, and as has been mentioned Mailman isn't a one-stop-solution-for-all-situations solution. There is also a lot of public misconception about Mailman in general -- things you only realise when you're actually implementing it on a box or run into trouble. I doubt anyone is to blame for this -- there are simply too many variables involved. I'd suggest to anyone looking at Mailman as a solution search the docs/FAQ/list-archives, *and* join the list and ask a few questions before actually implementing. It's a lot easier to anticipate certain things that way. :-) -- | Bretton Vine | 083 633 8475 | [EMAIL PROTECTED] | | GPG: http://bretton.hivemind.net/bretton_vine.asc | "Gods are fragile things; they may be killed by a whiff of science or a dose of common sense." - Chapman Cohen ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp