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

[Richard Wackerbarth]

I encourage any GSoC candidates to actively discuss design issues on this list. Many aspects of MM3 remain only partially defined and still require design in addition to the coding that will follow. Although some might expect the mentors might "spoon feed" coding tasks, as a mentor, I would prefer to work with someone who is actively involved in the design as well as the implementation.

Having looked at MM2->MM3 migration in the past (and deferred implementation because critical infrastructure was not available at that time) let me present a different perspective.

First, there are some parameters that do not relate to any particular mailing list.
IMHO, these aspects need not even be addressed in a conversion.
If I wish to set up a MM3 installation, I should first, manually, set up a sample list.
After I do so, the configuration of any "real" lists needs to be COMPLETELY configurable using the REST interface. If that interface is not presently adequate, it needs to be revised rather than "working around" any deficiency.

Therefore, I should be able to set up my "sample list" and, thereafter, add/edit all of the real lists utilizing the same interface (using mailman.cliient, etc.) that is available to the Postorius interface for list creation/editing. A migration tool would, therefore, need only "simulate" those manual steps that the installer would execute on a web-based interface to create a new list and adjust its settings.

Similarly, handling the subscriptions must be something that can be done using just the access exposed via the REST interface.

The big distinction between MM2 and MM3 lies in the conceptual model of entities. In MM2, each subscription is a separate entity. In MM3, subscriptions belong to "persons" and management functions are made available for the person to affect multiple subscriptions at the same time.

In translating from MM2 to MM3, the aggregation of subscriptions under a common "person" becomes a non-trivial task.
However the mechanisms required to handle reassignment are needed within MM3 implementations because there is an alternate access mechanism (admin by email) which cannot directly identify these "persons".

Therefore, I would suggest that a migration be broken into some components,
1) Migrate individual list parameters
2) Aggregate groups of lists
3) Migrate individual subscriptions
4) Aggregate subscriptions by "person".

Note that the aggregation functions for both lists and persons require similar mechanisms and that having the ability to edit those configurations within Postorius will be beneficial to both migration and routine system operation.

Richard


On Apr 11, 2013, at 3:11 PM, Barry Warsaw <barry at list.org> wrote:

> 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.
> 
> 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.
> 
> List-specific configurations live in the various config.db files for MM2.
> These are pickles.  In MM3, everything's in the database.