Personally, I'd much rather see the HT/Dig patch implemented before this one. That is IMHO more useful to the average mailman admin than this.
Bob ---------- Original Message ----------- From: Jeff Marshall <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: mailman-developers@python.org, [EMAIL PROTECTED] Sent: 05 May 2005 19:14:40 -0700 Subject: Re: [Mailman-Developers] Patch for Mail Archive mirroring > I figured I would attempt a brief summary of major points brought up > by the discussion. > > Concerns > - proper documentation describing the feature and possibly Mailman's > position on archiver tie-ins - make sure it defaults to off (it > currently does) - we should look for opportunities to add safeguards > - one possible safeguard - an option for admins to add the "X-No- > Archive: yes" header - has pros and cons (cons: does it conflict > with local pipermail archiving? possible conflict with user's X-No- > Archive intentions?) > > Is it an endorsement? > - people ranged from "seems like an endorsement" to "no more than > mailman endorses the other software it works with" - I'm happy to do > the work to make this feature work with other archiving services as > well. Gmane looks like it is out. I will check with Hank at MARC. > > Overall > - seems like most people think it is a positive patch (with the > caveat that it defaults to "off") because it makes things easy for > admins that choose to use it - in the end, it's up to Barry and > Tokio. Hopefully one of them can jump in briefly and make the call, > or ask me for some rework on the patch. > > Corrections or clarifications are welcome. > > Thanks to everyone for their consideration and response; people > seemed to put a lot of energy into this. Much appreciated. > > Jeff Marshall > [EMAIL PROTECTED] > > -----Original Message----- > From: Brad Knowles > Date: 5/3/05 1:56 am > To: Stephen J. Turnbull > Cc: mailman-developers@python.org, Chuq Von Rospach , Chuq Von > Rospach Subj: Re: [Mailman-Developers] Patch for Mail Archive mirroring > > At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: > > > 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. > > The problem here is that Mailman should not be adding an > "X-No-Archive:" header to messages that it is processing. This is > something that should be controlled from the perspective of the user, > and Mailman should not be stepping on their toes. > > Moreover, if Mailman did add such a header, what would happen to > the internal archiving system? Would Mailman ignore the header that > it has added while honoring the same header that might have been put > on the message by the user? > > As a list admin, I can see a strong desire to keep your own > archive, but to want to prevent anyone else from maintaining an > archive, at least not without your express approval. Unless, that > is, you gateway to USENET news, in which case Google and others have > news archives that you could not control and could not even be aware > of in most cases. But then if you gateway to USENET news, you > should be aware of this issue, and be prepared for what might happen. > > > 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. > > IMO, the ultimate decision is up to Barry -- it's his project, > and he gets to decide how things go. However, he is currently > focusing on Mailman3 right now, and Tokio is the release engineer > for Mailman2, and in the past Barry has been open to comments and > suggestions from others. So, I imagine he might make his feelings > known, but then leave the ultimate decision to Tokio, who would > hopefully also take input from others. > > However, I don't see that Mark or I would necessarily have any > more weight given to our comments during that discussion as a result > of our work with the FAQ and answering the questions. I would hope > that we would be heard along with the others commenting on the > subject, and appropriate weight would be given to them by Barry and > Tokio, but more based on their merits than on the work we do with > the FAQ. > > There are plenty of other knowledgeable people on mailman-users > and mailman-developers who don't (or haven't recently) done much of > anything with the FAQ, and I would hope that their voices would be > given as much weight relative to their experience as would ours. > > > 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." > > I'm not so sure this is a good idea. At least, not so far as > guaranteeing that it would be put in the next regular release. IMO, > if the patch defaults to off, and the service conforms to the > relevant RFCs and BCPs, then I think we should give it serious > consideration, but I wouldn't want to guarantee anything more than > serious consideration. > > > Or maybe it's worth encouraging such services, and being more helpful > > about it. > > I would encourage more people to make patches, and to try to be > more helpful about this process in general. But I wouldn't want to > make any guarantees as to what would/would not get included -- > everything should get the appropriate level of consideration, but no > guarantees beyond that. > > -- > Brad Knowles, <[EMAIL PROTECTED]> > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 > > SAGE member since 1995. See <http://www.sage.org/> for more info. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/marshman%40frozzenbear.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ------- End of Original Message ------- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
