On Dec 9, 2005, at 6:47 PM, Alec Mitchell wrote:

OK framework folks, here is a summary of the current state of things as per
our last discussion and some followup with the relevant devs.  I'd
appreciate any additions or disagreements:

PLIP #102: PlonePAS:
Another mature third product that is in production use, and for which the integration work is mostly done. Enfold is standing behind the product and it is apparently (nearly?) ready to merge. The TODO list indicates a few items that seem pretty important (role mapping, caching, listMemberIds), and migration needs to be tested on a few reasonable sites. A big lingering
question, what does this mean for CMFMember?

CMFMember will not work w/ PlonePAS, at all. chances are that it never will. my current thought is to write a new product, based on Membrane, that will replace CMFMember, providing a (hopefully ContentSetup-based) migration path forward. i'm hoping to start working on this at the snow sprint.

Does it matter?

i think it does. there are quite a few folks out there using CMFMember, and this is going to be a show-stopper for all of them. i think scrapping it and building a new product is the way to go, and i don't expect it to be terribly hard, but i'm not going to be able to do it alone. RockyBurt and SashaV have already said they want to help, it'd be great if we could get a few more hands.

PLIP #113: GenericSetup
This appears to be in good shape, and while it's only a gradual step towards a more reasonable migration and setup infrastructure, it is a very important one. The way that portal setup is performed on the branch currently creates some undesirable dependencies (making it so that AT and ATCT tests can't

i'm working on this now.

The production of some GenericSetup usage documentation would be nice
as well.

i'll get to that.

With some cleanup this branch should be ready to merge soon.
Would it be possible to convert ATCT to use GenericSetup as well for this

ATCT is already using GenericSetup, sort of... the setup profile for Plone specifies explicitly what types should be in the types tool, so the ATCT types are instantiated and used from the get-go, w/o the need to do the ATCT installation migration process. it would be nice to make this more complete, though. we'll see.


Framework-Team mailing list

Reply via email to