[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
release?
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
developed).
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.
Alec
More information about the Framework-Team
mailing list