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

[Barry Warsaw]

On Apr 11, 2013, at 07:02 PM, Richard Wackerbarth wrote:

>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.

Totally agree.

>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.

The REST API is pretty easy to extend.  By far the most time consuming bit
(assuming you know where you want your resources to live) is writing docs and
tests.  For many of the GSoC tasks, extending the REST API should be
considered part of the work.  This of course includes both in the core and in
the mailman-client wrapper.

>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.

Perhaps.  I think migrations could be done this way, but it's probably more
efficient to do it against the internal API.

>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".

Absolutely right.  It's an open question as to how to merge user records.
Because the user "databases" in a multi-list MM2 site are silos, there's no
connection between my settings in listA and my settings in listB.  How would
you combine those into a single user record for MM3?

Additionally, in MM2 you don't now that me1 at example.com and me2 at example.com
are both owned by me.  While it's probably impossible to merge these two
records when migrating them to MM3, we would like to have *some* way to merge
the two records once they're migrated to MM3.  We'd need to work out the
workflow for that, including any security guarantees, so that a user could
merge those records after a migration.

>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".

-Barry