On Aug 10, 2009, at 3:07 PM, Andrew Grover wrote:
On Mon, Aug 10, 2009 at 10:57 AM, Barry Warsaw<ba...@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 migrationheadaches. If this is something that could ease the migration to MM 3 by providing a 'stepwise' path, that would be great. However, if it isviewed 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
