I've looked at the patch, so let me give my general impressions, and then try to answer some specific questions brought up in this thread.
First, obviously this can't make it into 2.1.6, since that's imminent. The patch itself looks fine (i.e. no dotted T's or crossed I's :). But I would probably reject it anyway.
In principle, I like more general solutions and hooks for extensibility than hard-coding in external dependencies like this. For example, Mailman already has variables for hooking in external archives, so you could potentially re-implement your patch against that API. The one thing you'd lose is the ability to select mail-archive on a per-list basis. Is that important? I suppose some virtual hosting installations might want to allow that, but how common would that be?
Let's say that's an important requirement. What I'd like to see in that case is a way to specify multiple archivers, register these archivers with Mailman, and then give list owners the ability to select one or more of those registered archive methods. You could even generalize it so that the internal Pipermail archiver was just another one of those methods. /That/ would be a cool patch that I might support in a future version.
On Sat, 2005-04-30 at 04:01, Stephen J. Turnbull wrote:
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.
Right. If we had the general framework I outlined above, we could be pretty democratic about it.