Quoting "Rick Moen" rick@linuxmafia.com:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Just to reconfirm something I said the very first time this came up, SVLUG solves the problem totally transparently to the members, as follows:
(list subscribed to list ...)
At the time I suggested do likewise, I was told (here) that it was not possible to do it without problems.
I don't recall having said "problems" ... I did say "potential complications" ... perhaps not best wording, but in either case, each method has its own unique advantages and disadvantages. Either approach is valid and quite workable.
"Speaking" about the method chosen for BALUG, I earlier stated: < The above noted approach has the advantages of: < * it avoids the potential complications of lists subscribed to lists < and differing options/configurations (e.g. we want "announce" to be < non-digested, but we want folks to have digested form be option for < "talk"; if we subscribed "talk" to "announce", then those getting < "talk" digested, and not subscribed to "announce" would only see < "announce" within digested "talk" e-mails) < * it allows users to have separate per-list e-mail subscription < addresses if they desire such, and provides means for them to < request not being automatically added to "announce" based on < subscription to "talk" and/or "admin".
Anyway, ... those may not be exactly/precisely the various pros/cons comparing the different methods (and may also vary a bit depending on implementation details) ... but in any case, each method does have its own distinct advantages and disadvantages (e.g. list subscribed to list offers more simplicity in many/most ways; separate + (nearly) automagic addition +- exception mechanism allows some more flexibility, avoids some duplicate emails being sent to subscribers, allows users more per-list flexibility (e.g. distinct email addresses), but adds some more complexity for administration), ... and on and on one could go comparing them.
Anyway, the present BALUG method seems pretty well settled in and users (even newbies coming to the lists) seem to mostly understand it rather to quite well (as far as I'm aware, we haven't gotten a question or specific item about that from any subscriber (or potential subscriber) ... certainly not recently, perhaps not ever) ... and users seem to now mostly "do the right thing" when subscribing ... e.g. the number of folks I find subscribing to a BALUG list other than "announce", but not subscribing to "announce" is relatively small ... digging a bit more into list data (since the subscription totals don't reflect turnover information) ... between 2009-01-10 2009-03-27 total turnover on all BALUG's lists (adds and drops less auto-add) was 36 ... plus 3 auto-added ... so seems well over 90% get it right (rough small number statistics figure anyway - I don't think I saved more detailed historical "auto-add" data for more detailed analysis). So, ... being lazy(/efficient :-)) ... since it seems to work rather/quite well, I'm inclined to leave that general setup as it is (if it ain't broke, don't fix it). It also lends itself well to (future) automation. The script bits that do the "heavy lifting" (logic) - pretty compact, per wc(1): 7 40 365 With mailman CLI commands, cron, and a wee bit of glue logic/script, that can become fully automated process (well, except adding/removing email address from the "exception" list - but thus far there have been zero such requests - so that seems pretty easy to maintain).
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000419.h...