[I've CC'd majordomo-workers because things seem to have piped up there,
but keep in mind that most of the development effort happens on mj2-dev.]
Here are some minor issues I've noticed recently:
1) The help file for createlist is a bit out of date; it says that we don't
do automatic MTA configuration (which we do) and it mentions a problem
with the deletion of a spurious comma in the generated aliases which I
don't think is correct.
2) who-bounces doesn't show anything if the only bounces are older than 30
days. I think this is incorrect; if I set bounce_max_age to six months
(for, say, a low traffic announcement list) I still want to be able to
see who is bouncing.
3) We have several instances where a config variable takes a string like
"ORQ" instead of an enum_array of
owner
list
request
I started this dumbness with default_flags, but I think it needs to
change. I'd like to just break backwards compatibility with this
instead of writing a bunch of specialized parsing functions.
4) We need to force an upgrade to the latest MIME-Tools. Once we switch,
the code won't work with MIME-Tools 4.
5) I wonder if we couldn't get a volunteer to go over all of the config
variables and rate them according to "expert level". A future feature
would give us the ability to "hide" the more complicated variables from
novice list owners. All this means is that groups, particularly the
"ALL" group, would appear to have fewer variables in them when an
"expert" variable is set to something low. We might also have simpler
comment text for some variables at some levels. (This would be useful
for 'digest', I think.)
This just involves reading the variable descriptions and rating the
variable from 1 to, say, 5, with 5 being access_rules and 1 being
description.
Also, in most cases we have a simple set of variables to control some
important functionality in a basic way (i.e. *_access) and a set of more
complex variables for more fine-grained control (access_rules). We need
to identify places where this is _not_ the case and decide if we need to
provide a simpler set of alternate functionality.
6) We haven't yet begun to think about what to do with bouncing digests.
7) I recently received a complaint about Majordomo1 to the effect that the
default admin_body checks were dumb. We need to review these for Mj2.
For instance /\bcancel\b/ is a really, really foolish check. I would
also like to revisit the default checking depth of ten lines for admin
checks. Three makes much more sense to me, and is what I've been
running for about four years now.
Enough for now.
- J<
|
|
