[Mailman-developers] prerelease feedback

Ken Manheimer klm@python.org
Sat, 11 Apr 1998 14:08:32 -0400 (EDT)


On Sat, 11 Apr 1998, Scott wrote:

> atleast one of the wrappers (cgi-wrapper) was seg faulting on my
> machine (linux2.0.29 on a pentum).  i haven't completely traced and
> fixed the problem yet, all i've done is commented out the
> check_caller() function call to make it work in the meant time.  i'll
> track this one down more thoroughly early next week.

Ok.

> the integration with the archiving is still using pipermail v.02.
> it's unclear to me whether archiving is going to be done separately
> (with it's own cron jobs) or called via Archiver.UpdateArchives.  i am
> also unsure by what mechanism private archives are going to be hidden
> (via cgi password authentication, .htaccess or what).

I'm not clear exactly what you're saying.  My intention was to deprecate
but not yet remove all the stuff that implemented the internal pipermail
processing.  That amounted to commenting out some stuff in
mm_archive.py, removing the archive-job entries from the crontab
template, and so forth.  The actual messages are deposited, using some
remaining mm_archive.py methods, in files in either the public or
private dirs, according to the configuration settings.  Pipermail is
supposed to be pointed at the directories, with the private stuff hidden
behind a password wrapper, which i'll be including in my final package.
(I also added another setgid cgi executable wrapper in the src dir
makefile, etc - all of got finally working yesterday, so it's not in the
package i sent out thursday eve.)

> overall, i'd like to say yet again that mailman seems to be developing
> very quickly and extend thanks to ken and john and andrew.

Thanks!  I'm looking forward to the kind of growth we can get with more
contributors.  Though that also has me a bit daunted, and had me a bit
compulsive trying to polish up one thing or another, so people didn't
build on, and lock in, shaky foundations.  (Turns out there's never
enough you can do about that - there's always going to be some wrong
turns taken...)

Ken