[Mailman-Developers] Patch for Mail Archive mirroring
Stephen J. Turnbull
stephen at xemacs.org
Tue May 3 10:37:46 CEST 2005
>>>>> "Chuq" == Chuq Von Rospach <chuqui at plaidworks.com> writes:
>> the 3rd party archiver.] I don't see why Gmane or the Mail
>> Archive should have to obey special rules here.
Chuq> because it's the list owners list, and they have the final
Chuq> say on how its run. Not the users. If the users don't like
Chuq> it, they can go start their own lists, not attempt to co-opt
Chuq> policy on someone else's list.
That's not the point here. The special rule I'm talking about is the
one that says they must guess what (unpublished) policy is because
they're somehow "different" from "ordinary" subscribers. The examples
(Gmane and Mail Archive) are habitual good citizens.
Sure, they _are_ different, in a relevant way---they exist to broaden
distribution, including archiving. But I think that in the great
majority of cases where random users can just sign up, that is a
service to be encouraged. It's not a good idea to put the burden of
proof on them, when either the list-owner can be more selective about
membership, or they can use X-No-Archive.
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.)
>> ... 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?
Chuq> then we disable the patch.
Good trick, that. Mailman is free software; it will be months before
the revised code propagates to all the major distros, 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
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the Mailman-Developers