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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
