[Mailman-Developers] Patch for Mail Archive mirroring

[JC Dill]

Stephen J. Turnbull wrote:

>The second is that this patch evidently constitutes a significant
>endorsement of The Mail Archive.  As I understand Jeff's post, he went
>to the trouble of asking Lars if he would like a similar setup added
>for Gmane, patch to be coded by Jeff || Jeff.  I have to admit that
>somebody who would go to that much trouble to implement the same
>feature for a close substitute sounds pretty endorsable to me!
>
>... if Mailman is going to endorse services that way.  I don't really
>think it's a good idea in principle, though.  What happens if The Mail
>Archive goes away or goes proprietary?  What are people going to think
>if The Mail Archive's maintainers hire Barry or Brad?  Etc, etc.
>
>On the pro side, there is the point that this would make such
>mirroring an opt-in on the listmaster's side, which is good.  So it
>might be worth Mailman thinking about under what conditions it would
>be good to make such an endorsement, and adding anybody who satisfied
>those conditions.
>
I personally don't see it as being a significant endorsement.  AIUI, 
it's a patch that allows 2 software programs to work well together.  
Mailman already provides patches or directions to make mailman work well 
with qmail and postfix, but I don't believe this constitutes an 
"endorsement" of qmail and/or postfix.  Patches/directions that make 
mailman work well with archivers are similar - both with local archiver 
software and with mirror "site" archiver software.  The documentation 
for these patches (or directions) should simply make it clear that the 
other programs - *all* the other programs (qmail, postfix, MHonArc, 
gmane, Mail Archive, etc.) - are not Mailman programs, and that the 
patches (or directions) are included solely for those who want to make 
mailman work well with the indicated outside-provided software or service. 

A simple patch philosophy that will address this and future patches:  If 
the patch is incorporated into the main mailman build then the default 
state should be "off" so that the listmaster has to proactively turn the 
feature "on" for their mailman list server.  If the patch remains as an 
add-on feature that has to be downloaded separately from the main build, 
then the default state could be "on" (since downloading the patch 
separately would be a clear indication that the listmaster desired to 
implement this feature on their mailman list server).  This should be 
the same for all patches that specifically enable cooperation between 
mailman and any other outside-provided software or service.

IMHO, etc.  Caveat:  I'm not a developer so those of you who actually 
write code and build/install the software (I just run it after someone 
else installed it for me :-) have much more say on this than I do.  So 
if you hate my idea, speak up!

jc