[Zope-dev] Zope 2.13 roadmap

Thu Apr 1 03:33:22 EDT 2010

Hanno Schlichting wrote:
> On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli<optilude+lists at gmail.com>  wrote:
>> What's the next step? I'd love to see some roadmapping ala that you did
>> for Plone 5, in particular to discuss our WSGI story (which I'm
>> interested in helping out with if others can help too).
>
> There's no big roadmap yet, but I have some ideas :)
>
> In general I'd like to avoid a major Zope release, that isn't used by
> an official Plone release. Zope 2.11 hasn't seen much attention and we
> had to maintain 2.10 anyways. But if there's a decent and stable
> feature set that other consumers like to get there hands on, we can
> get them a release. I just won't be pushing into that direction.
>
> Here's what I can see today:
>
> There's a bunch of stuff already done as noted in
> http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?view=markup.
>
> - zope.app removal
>
> This project is all finished. Zope2 doesn't contain any trace of
> zope.app or the name Zope 3 in itself nor its dependencies anymore.

Cool.

> - Moving formlib out of the core
>
> Triggered by the above and finished as well. Zope trunk doesn't
> contain any trace of formlib anymore. The relevant code is now in the
> five.formlib package. This package is also included in Zope 2.12, so
> you can start using the functionality and be compatible with both Zope
> versions. CMF does this already.

Cool.

> - WSGI
>
> I cannot tell at the moment. It's going to depend on the actual
> changes required to get this to work. Since there is some broken WSGI
> support inside the 2.12 codebase, we can claim a certain deal of
> changes as bugfixes. But there's limits to what we can warrant as a
> bugfix. If the code changes are self-contained and only touch the
> broken WSGI modules, we are good. If we require changes all over the
> board for whatever reasons, this will have to be a new feature and go
> into Zope 2.13. Only a branch with actual code will tell :)

It'd be interesting to see what comes out of the PSU sprint Tres talked 
about. I have an interest in this, so will be happy to help, though I'll 
not be able to drive it entirely.

> - ZTK
>
> As long as there's no formal release of the ZTK or a defined and
> stable process around it, Zope 2 defines its own KGS. It so happens to
> use exactly the same versions as the current ZTK trunk. Once we are
> making progress on the ZTK release, we'll see how Zope 2 can use such
> a release. My current guess is that Zope 2.13 will use some ZTK 1.1
> release.

+1 - I think there's a big win from this. I also hope we can squash all 
the "what is the ZTK" debates. At the end, it feels like a lot of 
bike-shedding.

> - Five deprecation
>
> I did a whole bunch of work on this already and keep working on it.
> The end goal is to be able to deprecate the entire Products.Five and
> phase it out of the core. Actually useful functionality in it, is
> integrated into the proper places inside the Zope2 core packages
> instead. Like security stuff in AccessControl, container events in
> OFS, reading site.zcml and setting up the CA in Zope2/App and so
> forth. There's a number of hard cases, where there's some semantic
> differences between zope.* packages and their Five equivalent,
> especially in the "browser" realm. This project might not be
> completely finished for 2.13. And yes, there's some difficult
> questions with non-obvious answers around this. We'll deal with them
> once we get there. I'm focussing on the obvious parts first.

+1 - sounds hairy, though.

Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView 
(already done, I guess) would be a good starting point.

> - Reduce C code in Zope 2
>
> My first part of this was discussed and implemented. The remaining C
> code inside the Zope 2 distribution is in AccessControl,
> DocumentTemplate and ZCTextIndex. We'll see what to do about them,
> once their packages are actually self-contained.

I'd also like a more sane/documented/debuggable AccessControl. Sigh.

> - Make Zope 2 more modular
>
> This is related to the above two points. I'm not quite sure about the
> details of the implementation yet. But in general it would be nice, if
> a consumer of Zope 2 could use it's core, without getting a whole
> bunch of stuff it doesn't want. The obvious example here is Plone,
> which continues to use less and less code from Zope 2, but has no
> chance of making a radical cut and loose it all. There's interesting
> problems, like being able to use Zope 2 without the ZMI. In some sense
> this is similar to using the ZTK instead of zope.app. The only thing I
> know for sure, is that I'd like to first make the packages inside Zope
> 2 standalone and reusable and only once they are, break them into more
> distributions. We've gone the other way around with Zope 3 and it has
> cost a whole lot of pain.

I think it may help to make a list of the things we'd like to be able to 
get rid of, and then isolate those.

> - ZODB 3.10
>
> Jim promised a second alpha release to be out shortly. Should be low
> risk to upgrade to it. The multi-threaded ZEO server promises some
> good improvements.

+1

> - Python 2.7
>
> This would be 2.7 support in addition to the existing 2.6. Last time I
> checked all Zope 2 tests passed. But there where some hairy looking
> test failures in zope.proxy and some more in RestrictedPython.
> RestrictedPython will also need a new security review to make sure it
> continues to work with 2.7.

+1

> - Python 3.x
>
> Not on the agenda. We'll need to tackle this on the ZTK level first.

Personally, I think this is too unrealistic right now to expend much 
energy on. I don't see any good reasons right now to try to move to 
Python 3.

> For an actual timeline, it seems autumn this year is the earliest any
> 2.13 could come out, so it properly supports Python 2.7 and we have
> something definitive on the ZTK matter. But I'm not going to rush this
> and it's somewhat more likely we'll end up with an ever later release
> and match the Plone 5 release schedule.

One thing that would be interesting from a Plone perspective is whether 
people could optionally use Zope 2.13 with Plone 4.x. That may be quite 
attractive if Zope 2.13 has WSGI.

Martin

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