[Framework-Team] Current PLIP status

Alec Mitchell apm13 at columbia.edu
Sat Dec 10 02:47:30 UTC 2005

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 #12: Messaging channel:
	The PLIP needs to be updated to reflect what the implementation is actually 
doing ASAP.  Without some more concrete idea of the purpose and risks of 
this idea it's not at all clear if it belongs.  Currently the implementation 
provides for delayed cataloging, which is nice (especially if it can be made 
configurable).  We need an analysis of how this interacts with Five's 
monkeypatching of manage_* methods for events and the event work being 
proposed for CMF 2.0.  This PLIP involves pretty deep infrastructure and a 
strong argument could be made that, if this is to be done, it should be done 
in CMF itself.  Getting input from the CMF folks on why this is 
great/terrible would be worthwhile, even if it's no feasable to push it down 
the stack.  I've been assured that the code is functional, and it looks 
reasonable, so what remains is for it to be properly PLIP'd and documented 
(esp. a TODO).

PLIP #52: Placeful Workflow:
	CMFPlacefulWorkflow is a mature product, and integrating it into plone has 
clear benefits (locally configurable workflow mappings have broad utility).  
Some ui work needs to be done (this is true of workflow ui generally), and a 
discussion needs to be opened with the CMF folks, as this is an 
infrastructural piece that perhaps belongs lower in the stack.  The main 
impediment to polishing and merging this right now is that the primary 
developers (mroeder and encolpe) and still don't have svn access (!).  They 
have both submitted their contributor agreements, so some pressure needs to 
be put on the relevant persons to expedite this.

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?  Does it matter?

PLIP #104: Flon (TTW marker interface application and introspection):
	Perhaps this should be removed from the release?  Most of Flon has been 
integrated into Five and CMF (is this 2.0 only?).  Those bits that haven't 
been (catalog stuff), will not make it into this release as there's 
currently no code to review.  If someone wants to create a sensible Plone 
admin ui for these new features in Five/CMF it would gladly be accepted into 
this release.

PLIP #105: Five Views (generally)
	Work has been done on the goldegg branch and some of it appears to be in a 
good state.  The existing views need tests, and some benchmarks would be 
nice.  The major problem right now is that the goldegg branch appears to 
have some partially completed views and code that was badly ported from 
Python Scripts, that code doesn't appear to be used, but the branch is 
probably going to need to be selectively merged.  Somebody needs to stand 
behind the work in this branch, championing the particular work that should 
be considered for Plone 2.5, and doing the remaining work to get those bits 
ready for inclusion.

PLIP #106: Five Views for navigation:
	This is an area in which the goldegg branch seems to have been fruitful.  
The two different breadcrumbs implementations seems a bit redundant (the 
physical one is more correct IMO), and it's not clear to me what the purpose 
of the RootPhysicalNavigationStructure is.  Tests for these views are 
needed, though the existing tests for PloneTool are probably sufficient in a 
most cases.  A decision needs to be made about how to deprecate the 
PloneTool methods in favor of the views.  No new architecture for the 
portlet fetcher has been presented, if such a thing is to be considered for 
release there must be a working, tested version in svn within 2-weeks time 
(this extension is due to the fact that this would be an important 
demonstration of views in Plone, and most of the portlets themselves already 
have views).

PLIP #108: Zope3 MessageID's
	The work on this branch appears to be complete and ready to merge.  
Unfortunately, it is intertwined with the PLIP #111 implementation which 
currently depends on sessions.  Hannosch is working on a session free 
implementation, which should hopefully be complete in the next two weeks.  
In the worst case the session based implementation may be acceptable, as 
requests that generate a portal_status_message are relatively infrequent so 
the session impact is likely to be minimal.

PLIP #111: New portal_status_message infrastructure
	See above.  The PLIP needs to be updated to describe the new implementation 
once the details are worked out.

PLIP #112: XML Import / Export
	ContentSetup has a reasonably long TODO list and is completely lacking 
tests.  In order to be considered for release it will need to grow some 
sensible tests and probably support delaying reference handling on import so 
that cross references between imported objects don't fail randomly.  It also 
needs some Documentation and perhaps a ui.  Because this is an important 
infrastructural piece which offers large potential benefits in the future 
and doesn't affect existing behavior, it doesn't have to be perfect, but 
there needs to be some demonstration that there are developers behind the 
code who are willing to push it forward.

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).  The production of some GenericSetup usage documentation would be nice 
as well.  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 

PLIP #114: New version numbering for releases
	There seems to be a clear consensus on this, so 2.5 it is.

PLIP #115: Deprecation policy for ui elements
	This will become important as we move from python scripts to views.  Now is 
the time to put a policy in place, even if it is as simple as a 
plone_deprecated skin layer.  This is relevant to the goldegg stuff as that 
work is presumably resulting in the deprecation of a few scripts.  Those 
devs responsible for replacing script functionality need to make sure they 
formally deprecate the old script or template.

So that's it for the PLIPs, here's my proposed release schedule:

Dec. 24:  Those PLIPs that are essentially on probation (#12, #105/#106, 
#112) need to have demonstrated their readiness by this date.  That means 
documentation, active development, and some communication.  In particular 
#12 needs an updated and comprehensive PLIP with risks and an assessment of 
where it fits into the event driven future of CMF; #105/106 needs someone to 
say which pieces are ready, write tests for those pieces and formally 
deprecate the old bits that they obsolete; #112 needs tests and some 
demonstration that some progress is being made on the TODO items (primarily 
it needs to show that it is not a dead end, and that it will be actively 

Jan. 3:  Final day for merging of alpha1 features.  Those branches which will 
be part of the first alpha will need to be merged by this date.  The days 
after this will be dedicated to making sure all the pieces play nicely 
together and wrangling up tarballs for all of Plone's dependencies.

Jan. 6:  Public release of alpha1.

Jan. 17: All branches which hope to be included in Plone 2.5 will be merged 
by this date.  This is the date at which the feature list of Plone 2.5 will 
be set.

Jan. 20: Public release of alpha2, which will be feature complete but likely 
riddled with bugs.

Feb. 4: The last day of the Snow Sprint (and my birthday!), first beta 
publicly released.  There will have been two bug days by this point 
hopefully the obvious major issues will have been resolved.

Feb. 18: Two bug days later, beta2.

Mar. 6: Release Candidate, Monday before the Symposium seems like a good day.

Mar 20: 2.5 Final

Feedback on this schedule would be appreciated, especially from those with 
prior release management experience.  Once we've got some consensus on a 
feasible schedule, I'll submit it to the PF board.


More information about the Framework-Team mailing list