On Tue, 2005-05-03 at 04:37, Stephen J. Turnbull wrote:
Hrm. Maybe a way to turn on X-No-Archive should be part of this patch? (Or does Mailman offer that already? I don't see it.)
Not on the Mailman side.
Good trick, that. Mailman is free software; it will be months before the revised code propagates to all the major distros
Or years. It's bad enough I still get bug reports about Mailman 2.0, but there are sites still running <shudder> Mailman 1.x.
, let alone the small-time variants. How long would it take Apple to get a Software Update out? During that period, Mailman is offering a service that it can't support. Nor do I think Mailman's reaction would be particularly swift---isn't this the kind of thing that as a technical matter really should wait until the next scheduled release?
Again, I'm not really arguing against the patch. It's the people who might be doing extra releases (Barry and Tokio, right?) or answering the FAQs (Brad and Mark, primus inter pares) who should decide if it belongs in the Mailman distribution.
I do advocate some kind of public statement about the policy toward adding new facilities of this kind. One easy one would be "you write the patch, and show that you conform to certain rules such as 'patch defaults off' and 'service respects X-No-Archive as well as conforming to relevant RFCs', and we'll put it in to the next regular release that isn't already in feature freeze."
Or maybe it's worth encouraging such services, and being more helpful about it.
I think I've stated my general philosophy in a previous message. If WizzyMTA came with a new plug-in, documentation, and some promise of support help (if only to answer questions on mailman-users), we'd probably add the module in the next release. If we had a similar plug-in architecture for multiple 3rd-party archivers, we'd facilitate the same kind of thing for that service. I'd be all for that.