[Framework-Team] Re: [Plone 4] Zope 2.12 status

[Hanno Schlichting]

Hi.

As a general comment, it might be that selectively trying to backport
my stuff won't necessarily be the quickest way forward anymore.
Especially ones you hit stuff I did later on, it all moves to
dependency reduction and speedups, which aren't required to get the
stuff running on Zope 2.12. Working from the unittests / TTW-testing
until stuff works is another way to do it.

Keep in mind that the scope is about getting Plone running on Zope
2.12 and CMF 2.2, not about backporting all my craziness ;)

On Wed, Jul 1, 2009 at 8:33 PM, David Glick<davidglick at onenw.org> wrote:
> My todo list looks something like this:
>
> - track down and resolve the remaining 11 test failures in CMFPlone
> - start testing the other packages (and probably merging some more things
> for them)
> - finish making plone.recipe.zope2instance work for eggified zopes
> - sort out PloneFolder situation (it can probably go but I need to confirm
> that)

I think I responded to that already... it can go, as its only used
indirectly by the temporary folder from portal factory and some tests.
Or you let it stay. It doesn't matter much, as it's so little.

> - sort out actions API change (Hanno changed the way you fetch an action
> category on trunk; I haven't had a chance to look closely and figure out
> what the risks are yet)

I'd stay away from those. There's quite a number of evolutionary
changes made over time. The end result as seen today on trunk is
nowhere near what I'd consider to be finished. This is really a
separate change. Even in its minimal version it requires
backwards-incompatible API changes, that currently aren't documented.
It should also be a more conscious choice to break API compatibility
with the CMF actions API, which I did here implicitly.

> - sort out action icon changes
> - sort out plone.app.upgrades
> - sort out GRUF/PAS changes (on trunk Hanno removed the GRUF dependency and
> moved the tools to PlonePAS...I need to figure out how risky this is)

Merging all the functionality into one place and getting rid of the
GRUF package should be fairly save. It just needs BBB imports in the
old locations in CMFPlone, so that persistent versions continue to
work. We could either live with those BBB imports in place or write a
migration, which updates the persistent stuff to use the new canonical
import location. Or you don't touch any of this, as it's not strictly
required to get stuff running.

> - sort out KSS (actually this is already partially sorted out, I'm just
> waiting on commit access to codespeak)
> - sort out use of Globals and other deprecation warnings

That should all be fairly simple and just time consuming. It's a job
for grep after InitializeClass for the most part.

> - sort out javascript stuff (on trunk Martijn and Roel moved this to
> plone.app.javascript, I need to look more closely)

The p.a.javascript stuff also includes rewriting some of that JS to
jQuery and making a number of other changes. I'd just ignore all of
that and continue to keep the JS files as found in Plone 3.x.

> - sort out image traversal stuff / linkintegrity (image scales are now found
> via an IPublishTraverse adapter rather than __bobo_traverse__, which doesn't
> work during non-publish traversal, so linkintegrity fails to detect that
> images are linked in a document)

Huh? I thought that change was only part of Archetypes trunk and not
in the scope of Plone 4.

Hanno