[Framework-Team] Current PLIP status

Alec Mitchell apm13 at columbia.edu
Sat Dec 10 08:45:21 UTC 2005


On Friday 09 December 2005 11:04 pm, Rob Miller wrote:
> 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.

I think it does as well, a significant number of plone deployments use 
CMFMember, and not having a migration path for them is bad.  I wanted to 
make sure people feel that getting PAS in place now is worth this pain.  In 
particular I want to know that the CMFMember stakeholders are willingly on 
the PAS train. :)  It's probably unlikely there will be a Membrane based 
CMFMember replacement with migration of custom member types by the time 
Plone 2.5 gets released, so it's important that we have this out in the 
open.

> > 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
> > run).
>
> i'm working on this now.

Excellent, the test results you indicate in your following email are very 
promising.

> > The production of some GenericSetup usage documentation would be nice
> > as well.
>
> i'll get to that.

Great.

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

That makes sense, though it would be nice to have some add-on product 
available which demonstrates how to use GenericSetup to do installation 
tasks (if that's really possible at this point).  It's certainly not 
critical though, and perhaps ATCT is not an ideal candidate for that.

Alec



More information about the Framework-Team mailing list