[Mailman-Users] Re: remove this?

[J C Lawrence]

On Wed, 09 May 2001 15:33:47 -0500 
Bill Warner <lww at ictech.net> wrote:
> At 12:15 AM 5/9/01 -0700, J C Lawrence wrote:

>> Actually I buy and agree with both arguments, I just consider
>> them misplaced in this case.  They work very well elsewhere.

> I think they are appropriate here too.  It just seems to me that
> an adamant stance against configurability is actually more harmful
> to the stated goal of promoting wider acceptance of 2369 than
> allowing a per-list configuration would be.  

You may be right.  I look at it a little differently on the basis
that source is available, and that lsit admins, should they so need
to, can patch their source locally, and can find the relevant
instructions and patches in the archives should they so need to.
Unlike a closed source product the door is not slammed or locked
shut, there's just a lack of a neon sign telling you where the door
is.

> Here's why I say that:

> (a) Most mailman-owners will run with the defaults anyway, so all
> of their messages will still be 2369ized.

One of the advantages of the above
you-have-to-manually-patch-your-source approach is that most will
fail to maintain the patch across upgrades, and thus even if the
patch is variously adopted, it will self-select against itself over
time.  

> (b) Those of us that have problems in this area can 2369ize our
> lists one, or a few, at a time, where appropriate, and bring our
> users along at a rate that we can manage.  Since only we can
> determine what that rate is, only we can make that decision for
> ourselves.

Agreed.  Use of a good MTA ala Exim can also help here (you can put
in delivery time filters to strip the appropriate headers to do
whatever to the message(s)).  The question has never been about _IF_
you could do it, just about _HOW_.  

> So, bottom line, I agree that 2369 compliance is good for Mailman
> and a worthy goal for all mailman-owners.  A per-list
> configuration option would make it easier for me, and based on
> what I've read in the archive, others, to migrate towards full
> 2369 compliance, and therefore more likely that we'll do it.  That
> sounds like a good thing to me.

For reasons previously discussed, I'm not so keen.  Tho I do agree
that Mailman does not to properly support the concept of an
announce-only list, and should reflect that in the List headers.

> Anyway, <shrug>, that's how the picture looks from where I sit.

>> Trade offs.  The high road.  Those that leave are typically
>> (experience) better off gone, and (experience) their replacements
>> are much more valuable and numerous.

> I don't disagree with anything you said here about FAQs, user
> education, or customer/list member relations.  I think you are
> right on all counts.  The problem is, that at this particular
> moment in time, I simply cannot afford (in time or $$) to take the
> high road without just a little bit of help to make doing so a
> little bit easier.  If I have to deal with this issue on an all or
> nothing basis, it's going to be nothing.

<nod>

It is possible that Mailman is not the right MLM for your needs.

> In any case, Barry has said he'll consider the 2369 configuration
> issue for 2.1, and that's good enough for me!  

Given the current state of affairs, I would mildly encourage
(translation: I won't argue against it) the following:

  Arbitrary-person-who-is-not-Barry writes a patch to support
  2369 configurability and submits it at SourceForge.

  Minimal effort is excercised not to break the patch across Mailman
  versions.

Anybody who really thinks they need it can grab the patch and head
out on their own as/if needed.  

Its the old, "This is unsupported but you can do it" trick.

>> > We now return you to your regularly scheduled program about how
>> to > get Mailman to run on the Linux flavor-of-the-day...
>> 
>> Yea gods save us.

> Doesn't seem likely. ;-)

<sigh>

-- 
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows