[Zope-dev] Zope 2.13 roadmap

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

"GOOOOOOOOOOOOOOOOOOOOOOAL!  And the crowd goes wild!"

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

Yay!

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

My branch is here:

  svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-fix_wsgi

We'll see how it goes:  I would be comfortable backporting to 2.12.x
myself, unless something wildly unexpected turns up.

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

You're too optimistic:  I'm betting ZTK won't have made anything more
than a 1.0 release by then.

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

As you saw yesterday, we need to leave some more BBB lying around for
the moved functionality.

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

Getting the Hurt^WHelpSystem out of the way would make ZCTextIndex a
non-dependency of anything else: what if we made it a standalone product?

Disentanglingh DocumentTemplate and AccessControl is a wicked hard
problem.  I have a sense that we may need to create one or more new
modules as layers to fix the cycles in that graph.

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

Ideally, all of the 'Products' should be released (and some thereby
abandoned :) separately.

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

Yup.

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

I don't see any chance of getting ZTK compatible before the end of the year.

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

I would say that we need to push the Plone folks to change their policy
here:  their unwillingness to update from 2.10 to 2.11 was a major drag
on our process (we *still* to keep 2.10 alive).  In effect, all Plone3
users are *more* at risk because of that policy than if they had
upgraded, because they aren't getting high-quality support for the Zope
and Python versions they chose to freeze themselves to.

I would rather see smaller, easier, and more frequent 2.x releases from
Zope, with improved factoring and testability reducing the risks of the
update for Plone.

> All that said, we'll change plans if something comes up and a better
> plan suggests itself. The above list is obviously non-exclusive, so if
> someone else has anything he wants to work on, announce it, discuss it
> and we'll decide when and how it gets in.

Sounds good.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku04SYACgkQ+gerLs4ltQ6mQQCfbt1pPe7WnanRypKY4hpH2uAG
KCgAni1TTW5T5Zu0AzSP7YErnPLG/Yjo
=FakO
-----END PGP SIGNATURE-----