[Mailman-developers] Next Release

[Ken Manheimer]

On Sat, 28 Mar 1998, W T Hewitt wrote:

> I finally figured out the problem. I'd ftp'ed the file to a PC then to
> an SGI O2, and
> the klm.p1 had extraneous <CR>s in it!

Yikes!

> I've been using mailman on an SGI, and my problems/suggestions/fixes for
> the next release.
> 
> I'm willing to do some of them if somebody will tell me which ones to
> do:

I'm glad to hear your suggestions, and that you're interested in hacking
on the system.

> 1) in mailman/src/*.c put UID and GID in a .h file so I Only need to
> edit one file

I would appreciate this being done, but be careful to distinguish them
(and perhaps include more explanation about which is which).  I will
probably not do this myself.

> 2) Make /home/mailman a configuration variable

This would be good, but i'm not clear how it would be done in a general
way - specifically because all the files need to add the modules dir
path to their sys path, and they can't import anything or do anything
implicit until they have that info.  I'm inclined to think something
involving a relative path will be the answer, but that can get
complicated.

> 3) Make the logging files /tmp* world writeable (when debugging I had
> problems running as nobody and mailman)
>     and make the names consistent

I have implemented a generic file logging mechanism, one which does not
disrupt operation if log files are unreachable, and deployed the
mechanism everywhere that files were deployed, plus some places where
they weren't.  (It will be easy to plug in syslog as an optional
alternative to the file-based output, eventually.)

> 4) Use HTMLgen for creating HTML

Robin has looked at this a bit.  I'll be interested in his response -
but what in particular is to be gained by using HTMLgen instead of the
home brewed stuff?  It may be basic, but i'd think it'd be best to keep
the html layout simple, at least until we have the rest of the system
nicely polished, and can spend the attention on fancier layouts...

> 5) On SGI you can't add aliases to programs in /etc/aliases
>     You do it through a .forward file for /home/mailman
>     All names in /etc/aliases are therefore aliased to mailman, and I
> have a
>     mailwrapper script that does what aliases used to do.

Hmm, this is a tricky one.  If i recall correctly, on many unix systems
(ie, with recent versions of sendmail) you need an entry:

/SENDMAIL/ANY/SHELL/

in /etc/shells to enable program aliases.  Did you try that?  If that's
the problem, then the fix is to include an instruction about that in the
installation doc.  If it's not, then we'll want to include your
additional wrapper layer (but it'll be getting deep!-)

> 6) Add archive more frequently (e.g., daily, hourly, now) to mm_archive
> volume_frequency
>    I have a fix for this

I should warn you that in my new version i do away with the internal
pipermail and instead use a new version of andrew kuchling's pipermail
(which andrew is tinkering with here).  Therefore the archive frequency
depends on how often the pipermail archiver is pointed at the archives.
(Something high on my priorities is to provide private archives, in
addition to the public ones, which key on the maillist members
passwords.  We hope to have that together this or next week, and then
we'll be able to release a new version of mailman, with lots of stuff
like the above, together with the new pipermail.)

> 7) crontab on SGI complains about blank lines in crontab.in

On solaris 2.6 also - it's repaired.

> 8) Put all the files associated with a list in one subdirectory, that is
> independent
>    of mailman code.

Hmm - on one hand, i like the idea of consolidating the templates and
list data, on the other hand i want to be able to direct the list
traffic to arbitrary places, to organize them sensibly for, eg, external
archivers (:-).  I think this should be configurable, perhaps with
defaults that collect them together.

Speaking of defaults, another big change i've made is to collect
together all the default values from all the files into a single new
file, mm_defaults.py.  All the other files get their defaults from
mm_cfg, which gets the distributed defaults from mm_defaults (via 'from
mm_defaults import *').  This way, we distribute generic defaults in
mm_defaults.py, and sites put their local configurations in mm_cfg.py.
New distrbutions overwrite mm_defaults.py, not mm_cfg.py, so the local
settings are preserved...

There is a substantial number of other changes (eg, robin's nice
listinfo layouts, which you might have noticed in the python.org
maillists), but i've been too busy trying to get everything shipshape to
get around to tallying and packaging it all.

Ken