[Mailman-Users] Re: remove this?

[Bill Warner]

So, I lied about my previous post being my last, but on reflection perhaps 
some final comments are in order, or perhaps I just can't help myself...

At 04:54 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>This issue comes up again and again, and I apologize in advance if I sound
>(or sounded) grumpy about this

I, too, apologize, especially to Chuq and J C, for being grumpy, or rude, 
but on my side of the fence this particular issue is costing me real money, 
which tends to make me cranky.  Since upgrading my Mailman installation to 
2.x these headers have been the direct cause of new tech support calls, 
everyone of which costs money.

In the end, I think that any disagreement we may have over this issue is 
actually philosophical rather than technical.  Personally, I am a firm 
believer in the guiding principle of the X Window System which always seeks 
to "provide mechanism, not policy."  If you apply that principle to this 
issue, then you conclude that Mailman should implement the mechanism for 
sending RFC2369 headers, but the policy decision of which, if any, of them 
should go out on a particular list should be left to the list owner.  It's 
obvious that many here disagree with that design philosophy.  So be it.

It has also been said that because this is Open Source, I already have the 
ability to control this header behavior by hacking the source.  True 
enough, and I've already done that for my installation.  But I submit that 
deliberately making this kind of thing harder than it has to be, a kind of 
"Father Knows Best" attitude, is antithetical to the roots of todays Open 
Source movement.  Unfortunately, if you don't buy the "mechanism, not 
policy" approach then you probably won't buy this argument either.

Of course, through all of this the Mailman developers are free to develop 
as they see fit, and there is no requirement that I like the way they do 
it.  Conversely, there is no requirement that they, or anyone on this list, 
like the questions I ask about their product.

>But nobody is under any obligation to
>make that easy, to help you do it, or to give you instructions.

Of course not.  Neither are you under any obligation to reply to the 
question in the first place.  It has always seemed childish to me for 
someone to reply to a message only to say, in essence, "I know the answer 
to your question but I'm not going to tell you because you are either not 
worthy enough in some way, or I think you are going to do something silly 
with the information."  Why not just answer the question, or ignore it?

>Same with hacking list-*. The general consensus among those of us who've 
>put time into understanding this issue is that it's a very good thing for 
>the long-term development of mail list technologies.

I don't disagree with that.

>Short term, it's at best a minor irritant,

That, I strongly disagree with.  It may be a minor irritant to you, but it 
is much more than that here.

>and that's only to people with cruddy mail clients (consider
>it an incentive to upgrade to soemthing decent).

Unfortunately, the people I have to deal with don't see it that way.  They 
don't want anything to do with upgrades or reconfigurations.  As far as 
they are concerned this happened because of something that I did (upgrading 
Mailman), and they pay me $19.95/month, so I damn well better fix 
it.  While the customer is not always right, you sometimes have to pretend 
that they are.

>You're welcome to disagree -- but not demand that we help you do something

I apologize if you felt I was demanding anything.  That was not my intent.

>I get a little grumpy when people wander in telling me how things ought to 
>work when they've never been under the hood of a piece of email...

It's really not productive to try to guess some ones background based on 
one or two posts to a mailing list.  Just because I don't have the time to 
read mailman-users everyday, or hunt down every RFC that impacts it's 
development, or spend quite enough time to track down 
Mailman/Handlers/CookHeaders.py, doesn't mean that I have "never been under 
the hood of a piece of email..."  So, please, lets not get into a pissing 
contest.

[Oh dear me, I went and said the secret file name on the list, now everyone 
has the dangerous knowledge of how to get rid of the pesky RFC "mandated" 
List-* headers.  Whatever shall we do now?]  Ahem, sorry (sort of) about 
that, but I really couldn't resist.  I know, childish at best...

>Implementing list-* is investing in future technologies;
>footer data is managing today's users.

Exactly! My problem is that I have to manage today's users as cost 
effectively as possible, or I go out of business, and while I really do 
applaud the developers for investing in those future technologies by 
implementing RFC2369, I simply can't afford to have the cost of that 
investment coming directly out of my bank account.  So given that reality, 
what's so wrong with asking for an option that allows me to more easily 
control this trade-off?

I guess that's a rhetorical question, but as far as I can tell the only 
thing wrong with asking this particular question on this list is that 
people here are already entrenched in their positions on this issue.  In 
that case I highly recommend that the next time this issue comes up, as it 
surely will (which might be some kind of a clue), those who are tired of 
it, or offended by it, just ignore it.

Finally, my sincere thanks to all those who provided genuinely helpful 
replies off-list.

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

--Bill