"Chuq" == Chuq Von Rospach firstname.lastname@example.org 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 about it.