On Jul 13, 2011, at 04:51 PM, Paul Wise wrote:

By bounce I meant SMTP-time rejection, sounds like the LMTP stuff provides that (and mailman 2 doesn't use that IIRC).

Correct.

Temporarily failing lists were not an objective.

Cool, I think we're agreed on that.

The design of list objects seems to be heavily similar to how the UI is in mailman 2, I think it should be much more generic.

For example:

In the web UI turning on emergency moderation should set the first item in the receive pipeline to a hold() function.

Disabling a list would set the first item in the receive pipeline to reject_disabled, set the first item in the subscription pipeline to reject_disabled, set the first item in the settings pipeline to admin_read_only etc.

This isn't exactly how MM3 works. In MM3, the incoming queue sends the message through a chain, where each link has a rule and an action. An action can be something like "jump to the hold chain", which is in fact exactly what happens in the default built-in chain:

src/mailman/chains/builtin.py:

_link_descriptions = (
    ('approved', LinkAction.jump, 'accept'),
    ('emergency', LinkAction.jump, 'hold'),
    ...

There really aren't "subscription" or "settings" pipelines, and I'm not sure they're the right way to implement what you have in mind.

List objects should be flexible to support different kinds of lists, but the UI should hide most of that behind simple labels like "retired list", "public list", "private list" and the "emergency moderation" button.

MM3 has list styles, which are composeable and extensible. A style is only applied at list creation time though.

PS: Is there a Mailman UI yet? The link on the Mailman branches wiki page points to one with only one commit in it and no working code.

I think we're still waiting for Florian and the GSoC students to propose branch merges into lp:mailmanweb.

PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm thinking configuration filenames, data directories etc should be named mailman3 instead of mailman.

Maybe. I'd really like to not do that if it can be avoided. For example, the configuration system is so different I can't see how there would be much collision. The data directories, possibly, but I also think there are enough knobs to allow site admins or vendor packagers to set things up with the proper defaults. I don't think there will be any collisions on command line program names.

Cheers, -Barry