[Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2

Martin Aspeli optilude+lists at gmail.com
Sat Jun 20 10:17:04 UTC 2009


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: http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/CHANGES.txt?view=auto
> CMFDefault 2.2 changelog: http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/CHANGES.txt?view=auto
> 
> 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

+1

> - 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

+0

> - 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

+1

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

:p

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

Cheers,
Martin

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





More information about the Framework-Team mailing list