[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