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