-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
> On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <[email protected]> > 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 [email protected] 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----- _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
