[Mailman-Developers] Getting code in? (was: Storm basedMemberAdaptor for Mailman)

[Barry Warsaw]

On Aug 10, 2009, at 3:07 PM, Andrew Grover wrote:

> On Mon, Aug 10, 2009 at 10:57 AM, Barry Warsaw<barry at python.org>  
> wrote:
>> On Aug 10, 2009, at 12:38 PM, Mark Sapiro wrote:
>>
>>> My concern is to not create additional 2.1 -> 2.2 -> 3 migration
>>> headaches. If this is something that could ease the migration to  
>>> MM 3
>>> by providing a 'stepwise' path, that would be great. However, if  
>>> it is
>>> viewed as something that will be done for MM 2.2 and then totally
>>> redone for MM 3, I'm afraid it will just encourage people to skip MM
>>> 2.2 and wait for MM 3.
>>
>> The Storm based MemberAdapter is definitely a MM2-only thing.  The  
>> schema is
>> so different in MM3 I don't see it as being a possible stepping  
>> stone.
>
> One (bad) option would be to use a MM3-compatible schema for the new
> 2.2 code. This sounds bad for a few reasons: MM3 schema could change,
> and an incomplete implementation of the (large) schema in our 2.2
> Adaptor could increase the complexity and fragility of the upgrade
> process.

I'm not in favor of this because one of the whole points of having a  
MM2.2 was to keep the data model unchanged from 2.1, but to fix and  
improve other aspects of the system, such as the web interface, some  
of the defaults, etc.  Really fixing the data model should only happen  
in MM3.

Of course, I welcome all participation in that effort :).

> Have you given any thought yet to the upgrade process? I'm assuming
> there will be some utility to convert a MM2.2 installation to a MM3
> one? One thought I had was that this utility would likely use the
> Membership adaptor classes to pull data (as opposed to reading .pck
> files directly) in which case the data source of the member data
> should be opaque[1]?
>
> Thanks -- Regards -- Andy
>
> [1] of course if database or table names overlap, it goes boom

I have thought about this, and done some preliminary work on this, but  
it could definitely use some more attention.  It's absolutely critical  
that we have an easy migration mechanism before MM3 final can be  
released.  My current thinking has been to use a flat file format  
somewhat like what bin/export produces and have an import script in  
MM3 that collates and updates its data.  That's just a general  
direction though so lots of details need to be worked out.

Another thing I have not been good at is tracking the MM2.2 changes  
and 2.1 bug fixes.  At some point I'll have to do an audit of this,  
but it's too disruptive of my current flow to do that now. :(

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090810/3c253c2e/attachment.pgp>