[Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Patrick Bogen]

On 12/6/06, Jon Forrest <forrest at ce.berkeley.edu> wrote:
> I'm relatively new to Mailman but I've managed
> to build it from source and set up a few lists,
> with generous help from this list.
>
> While working through issues relating to
> creating a standard list configuration, I started
> to feel that there was a fundamental flaw in the
> way Mailman lists are configured that I couldn't quite put
> my finger on. Of course, this could be due me not knowing
> or understanding something, and, if so, I'll be happy
> to retract what I'm going to say below.
>
> Yesterday, I realized that I had made a mistake in
> how I had configured all my lists (I only have about
> 6 so far, so this is no great tragedy). This was entirely
> my fault, and not due to anything amiss in Mailman.
> So, using the web interface, I fixed the mistake on
> all 6 lists. This wasn't too bad, but it got me to
> thinking what I would have had to do if I had 1,000
> lists.
The command-line config_list and/or with_list tools have a slightly
higher up-front cost (in terms of work required), but trivialize the
cost-per-list for config updates, for the purpose of applying a single
value across multiple lists.

> All of a sudden the thought hit me that would it
> be better if Mailman lists were designed kind of like
> classes in an object oriented programming language.
> There would be one super list which would be configured
> with all the standard values you want every list to have.
> Then, there would be lists derived from the super list,
> which would only need to be configured to have values
> different than the super list. There could even be lists
> derived from these lists, and so on down the line.
Someone else can probably give a better analysis, but from my
understanding, something like what you're suggesting would represent a
significant departure from the current Mailman architecture, and this
would constitute a fairly major rewrite.

> With this design philosophy it would be very easy to
> make changes that effect multiple lists because the
> change would only have to be made in one place. I haven't
> thought it through but it might even be possible for this
> class-like design to include list membership making
> it easier to have one list contain other lists as members.
>
> Given that Mailman is written in Python, my naive impression
> would be that this should be relatively easy to implement.
> (As my old boss Mike Stonebraker used to say, it's just
> "a simple matter of software").
>
> In reading the Mailman documentation I saw a mention of
> an "umbrella list", but the only description here says
> "umbrella lists" are depreciated and will be replaced with
> a better mechanism for Mailman 3.0". Are umbrella lists
> somehow related to what I'm talking about?
Umbrella lists deal with lists that distribute their messages primarly
to other lists, rather than users. So, no, they aren't really related.


-- 
- Patrick Bogen