-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <optilude+lists@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@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-----