Hi David,

Hello! I'm hoping to give an update on my work this past week and get some feedback on whether I'm heading in the right direction.

I suspect you are. ;-) And let me just say I, for one, am really grateful you're doing this.

As some of you may have noticed, I've been working on a branch that can hopefully become the basis of Plone 4, including support for Python 2.6, Zope 2.12 (which is the first Zope 2 supporting python 2.6 and also the first official eggified Zope2) and CMF 2.2 (which will be the first CMF release that doesn't rely on Zope 2-style interfaces, which were removed in Zope 2.12...and also adds a few handy extension points). My basic approach is to start with the packages that make up Plone 3.3, and then backport the changes from trunk that seem non- risky. So far I haven't gotten through the entire history of CMFPlone trunk, nor through all of the rest of the packages, but I have at least gotten far enough to start up Zope and successfully add a Plone site.

w00t. :)

Do you have an idea of how much work is left?

Some of the changelogs that are relevant here, FYI:
Zope 2.12 release notes: http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html
Zope 2.12 changelog: http://docs.zope.org/zope2/releases/2.12/CHANGES.html
CMFCore 2.2 changelog: 
CMFDefault 2.2 changelog: 

As I've worked my way along, I've found myself making a number of judgment calls on where to draw the line between bugfixes and changes that are significant enough to warrant discussion. In case anyone cares to object, here are a few things I opted to include that I thought might be controversial:
- some optimizations coming out of the 2 performance sprints


- switching action icons to use icon_expr instead of portal_actionicons (hannosch) — see also http://dev.plone.org/old/plone/ticket/8801

+1 - I think this maybe deserves some discussion, but getting rid of portal_actionicons would be really good.

- switch to png icons (wiggy, dannyb)

+0 - maybe this will break some overrides, but it'd be nice to standardise on one format

- conversion of migration step registration to be based on GS upgrade steps (hannosch) - see also http://dev.plone.org/old/plone/ticket/8802

+1 - I think this will help our migration efforts in general

- c22120 and following - removal of the globalized variables for performance reasons (malthe, hannosch)

+1 - we need to do this sooner or later

- c22987 - remove unused Favorite content type (hannosch)

+1 - if someone is using this, it can be factored out to an add-on.

There were also a number of things I decided not to merge immediately until we can have some more discussion or finish some needed tasks. Some of these may not actually be desired until 5.0... I would really appreciate feedback here especially. - c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to double check whether this requires a migration for any persistent objects, and write that if necessary

+0 to remove.

- c20337, c20338, c22979, c22981, c22988 - switch the control panel to be based on normal actions in a new action category, rather than using a special control panel tool (hannosch) — see also http://dev.plone.org/old/plone/ticket/8804

+0 - we need to make sure the existing controlpanel.xml import step continues to work.

- c20365, c20368, c20369 — moved fullscreen css to a separate file (spliter) — needs a migration


- c22831, c22832, c22891, c22951 — remove external editor (hannosch) — see http://dev.plone.org/old/plone/ticket/8592

-0 - people do use this. what's the cost of keeping it?

- c22847 — remove wicked from core (hannosch) — see http://dev.plone.org/old/plone/ticket/8593 (but note that as of this week Carsten Senger has been doing some maintenance...yay!)

+0 to make this an add on people can install if they need it, but we should endeavour to make it work for migrated sites

- c22969 — removal of AT reference graphviz visualization (hannosch) — needs a migration to update actions for existing types

+1 to remove

- c23193 — turning default_error_message into a browser view (hannosch) — seems like a decent idea to me, but as implemented here it removes the redirector and content search features

+0 - I think ideally plone.app.redirector should just override this view and do nothing if not explicitly installed. I'm not sure we have time to do that properly, though.

- c23198, c23199 — removal of portal_interface tool (hannosch) — if we remove this then we lose the way to check for marker interfaces from action expressions, for instance. also, it's missing a migration

+0 to remove. Doesn't plone.app.layout.globals have something for this that's based on a view rather than a tool?

- c23226, c23233 — moving migrations to plone.app.upgrade and using all GS without the migration tool (hannosch) — -0 from me...I think moving these to a separate package may actually make it harder to keep migrations in sync with the Plone release they belong too, simply from the standpoint of reviewing svn history

+1 to move to all GS, at least. I don't have a strong feeling about the package location. Maybe Hanno does?

- c23335 — Changed workflow actor variable from user/getUserName to user/getId (hannosch) — needs a migration


- c23337 — Removed strangely implemented users search from the users folder (hannosch) — I didn't look carefully enough yet to see whether this is a good idea or not :)

Strangely implemented users search, ey? ;-)

- c23343 - Removed initial content from default installation (hannosch) — This probably does belong in a profile in a separate package that is included by the standard installers. But creating that hasn't been done yet.

-0 - I think Plone needs to ship with some default content. Where it lives I don't care.

- Consolidating the skin directories into just plone_browser, plone_resources, and plone_images....plus moving 3rd party javascripts to plone.app.javascript. — I'm -0 on this. Keeping the old layout would make it easier to merge things from the 3.x branch; switching to the new layout would make it easier to merge from trunk. Keeping the old layout has the advantage of not obsoleting a lot of existing documentation, and not changing something that we think there's a good chance we'll change again in 5.0 when we hopefully have a better unified Zope 3 vs. CMF skinning story.

-0 - I agree with you. I think we should tackle this by getting rid of skins altogether. :p

- Archetypes c8430 — return unicode encoding by default (hannosch) — My charset and encoding fu is weak. Is this what we want?

+1 to make Plone all unicode, all of the time. I defer to Hanno, though.

Some more general comments on risks / outstanding concerns:
- I need to finish going through the changesets that I haven't looked at yet.

How much work remains?

- There are a number of failing tests in CMFPlone that need to be investigated, and I haven't even tried to run the tests in most of the other packages yet.


- The current situation with regard to PlacelessTranslationService needs to be reviewed to make sure that our language negotiator and product i18n dirs are still getting registered properly following simplification/removal of Five's Zope2 i18n integration layer. Hanno said he could probably take a look at this.

Let's hold him to that. ;)

- I switched back to Zope 2.12.0b1 for now because with Zope 2.12.0b2 there is an issue preventing the Unauthorized error when you first try to access the ZMI from getting propagated into an HTTP authentication request. I haven't had time to dig into this yet although I did check a non-Plone Zope 2.12.0b2 and it didn't seem to be an issue there.

Weird. Maybe to do with our force migration of the root acl_users to PAS?

- We need to make plone.recipe.zope2instance work with an eggified zope. Currently it doesn't know where to find the mkzopeinstance script or other skeleton configuration. I made a quick hacky branch to make my dev buildout work, but this needs some more careful work.

Do we? I thought we could basically get away without an instance at all (but then where do we put 'Extensions' and 'import'?), just depending on the right things and generating a zope.conf and a startup script? I haven't looked into it, though.

- I commented out references to KSS rather than trying to make the adjustments needed to make it work, since there's been some discussion of removing KSS from Plone core and because I don't have access to the KSS repository.


- CMF 2.2 has not yet been released, and Zope 2.12 is still in beta. So we'll need to do some coordination in terms of release schedules.

Sounds like fun.

If you want to try this out / contribute, the mr.developer-based buildout is at http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/davisagli-zope212-cmf22-compatibility.cfg ...if you find a changeset that still needs to be backported, please feel free to do so as long as you make sure the svn mergeinfo remains accurate.

How would I do that?


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

Framework-Team mailing list

Reply via email to