[Mailman-Developers] Hi from a student interested in a GSoC project

[Elias Assarsson]

I appreciate the help in trying to understand the configuration systems 
in MM2 and MM3.

2013-04-11 22:11, Barry Warsaw skrev:
> On Apr 11, 2013, at 02:22 PM, Elias Assarsson wrote:
>
>>> * MM2's configuration file is a Python file which really must be imported
>>> in order to get a valid set of values.  MM3's configuration file is a stack
>>> of .ini-style files.
>> I am trying to find and understand the configuration files so that I know
>> what that that needs to be migrated and to what form. Is the MM2
>> configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration
>> files src/mailman/config/* and /src/mailman/<listname>/*?
> Yes, in a deployed Mailman 2, mm_cfg.py will contain the system configuration
> settings.  These override the settings from Defaults.py so a good way to
> explore is to use `bin/withlist` and `import mm_cfg` at the Python prompt.
I have had a look through bin/withlist, mm_cfg.py and Defaults.py to get 
a feel for the format of the configuration. Why is bin/withlist relevant 
for configuration migration? In that it is way to learn about configuration?
>
> In MM3, we use lazr.config, which is essentially a configparser type package
> that allows for stacks of configurations, with pushing and popping values on
> this stack.
>
> http://pythonhosted.org/lazr.config/
>
> The src/mailman/config/schema.cfg file is at the bottom of the stack and
> defines the schema, obviously :).  From there, src/mailman/config/mailman.cfg
> essentially instantiates this schema, providing all the defaults.  In the
> testing environment, src/mailman/testing/testing.cfg gets pushed on top of
> that (and many tests push and pop micro-overrides).  In a deployed system, the
> site's mailman.cfg is on the top of the stack and so can override anything.
> There are various places this mailman.cfg file is searched; see
> src/mailman/core/initialize.py for all the gory details.
I have had a quick look at the lazr.config documentation and also 
checked out mailman.cfg, testing.cfg and initialize.cfg in trying to 
understand the system.

I guess configuration migration scripts should have tests, e.g. to test 
if some particular MM2 configuration is migrated to the expected MM3 
form. If this is so, what would be an appropriate way to collect a MM2 
configuration and the expected MM3 form?

- Elias