[Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 andPostorius 1.0 alpha 1

[Barry Warsaw]

On Mar 27, 2012, at 05:20 PM, Jeff Breidenbach wrote:

>What is the incantation for enabling an external archiving service?
>Currently I only see this in mailman.cfg after following 5 minute guide.
>
>[runner.archive]
>class: mailman.runners.archive.ArchiveRunner

That configuration variable just sets up the appropriate queue runner.  Of
course without that, nothing would get archived, but it's not the interesting
bit from your perspective. :)

(I know that figuring out the configuration ini-file stack can be a little
confusing; we need better/more docs!)

So, every archiver that Mailman knows about will have a section such as

[archiver.<name>]

where <name> can currently be mhonarc, mail_archive, or prototype.  It
shouldn't be difficult to add new archivers by doing something like this in
your mailman.cfg file:

[archiver.hyperkitty]
class: sys.path.to.my.module.HyperKittyClass
enable: yes

It's the 'enable' variable that defines whether the archiver is enabled
system-wide or not.  This is documented in schema.cfg (think: the bottom rung
of the ini-stack, although it's slightly different than mailman.cfg).

(Aside: I think I need to start a YouTube channel on mm3 :).

The template for archiver sections is the [archiver.master] section in the
schema.cfg.  You'll see all the standard configuration variables defined
there, with their default values.

These are all site-wide configurations which define, enable, and configure the
various archivers available to the system.

Mailing lists themselves have a more limited palette (currently) for
configuring their archiving behavior.  There are two list-specific values:

 - IMailingList.archive is a boolean which determines whether the list will
   archive its messages at all or not.  The default list style sets this to
   true.

 - IMailingList.archive_private is a boolean only consulted in the
   mail_archive archiver.  If this is true, then it will not email messages to
   that service.

I've thought about giving more control to individual lists, but I'm not sure
how much value there is in allowing a list owner to e.g. decide which of the
set of enabled archivers their messages get forwarded to.

>> archivers are configured site-wide, so there's almost nothing
>> to expose in the web-ui.
>
>I'm worried about confusion. The last thing we want is for a list to be
>accidentally archived contrary to the list administrator's wish. It sounds
>scary to me not to have any indication whatsoever in the web
>interface.

Ah, sorry, yes the two booleans above should be exposed in the REST API.

https://bugs.launchpad.net/mailman/+bug/967238

I've marked it 'easy' and I think it would be.

I'm not sure whether you're asking if the ini-file settings should be exposed
in the REST API.  I'm much less certain about that.  I think it wouldn't be
difficult to expose them read-only, but I'm hesitant to let REST clients
change mailman.cfg variables, especially because having them take effect would
require a restart.

>Along similar lines, there seems opportunity for confusion if there are
>two independent mechanisms for archival; site wide configuration and
>also manually subscribing an archival subscriber such as
>archive at mail-archive.com. I can imagine someone turning off just
>one of these two mechanisms then being surprised that it had
>no practical effect.

Hopefully the above explains things.  The mail-archive implementation of
IArchiver does just email the address specified in
[archiver.mail_archive]recipient, but it won't do this if the mailing list's
.archive_private setting is True.

Suggestions for better integration are welcome.

>Finally, it sounds like there are architectural reasons for having
>archiving a site-wide configuration. But I do think list admins would
>appreciate some sort per list GUI option, to easily distinguish
>between public and private lists. These are often different folks
>from the sysadmin who can apt-get install mailman without
>giving a first glance at the mailman.cfg file.

Hopefully the above explains the state of things.  The system needs to know
about all the available archivers, but list admins do have some small amount
of control over whether their list gets archived or not.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120328/fe5d5515/attachment.pgp>