April 2010 - Zope-Dev

Zope2 - Release Manager
by Hanno Schlichting 02 Apr '10

02 Apr '10

Hi there, I was in too much of a good mood while having some vacation. So I thought I need more work to do :) I'd like to step up as the release manager for Zope2 for the 2.12 and 2.13 (trunk) releases. I've gotten an overwhelmingly positive response to this proposal from the Zope Foundation board. The ZF board was discussing a general release manager process. This discussion will become obsolete, should nobody in the Zope2 developer community have significant objections against my proposal. Unless there is a real need for it, the Zope Foundation will continue to stay out of direct decisions on the development process. Q&A Who am I? I'm going to assume everyone on this list knows me by now. Should you have any questions, please feel free to ask. You know this is Zope2 and not Plone? Indeed. I hope I have shown in the past, that I'm able to distinguish between the two. And what is appropriate and sensible for Zope2 with its many different consumers. Plone might be a major consumer of Zope2, but it's not the only one. Since I only use Zope2 as a base for Plone, I do have a certain bias. Wait, you say 2.12 and 2.13, what about 2.11 and before? Sorry, I have to pick my playground. The non-eggified Zope2 releases are very different in their release procedures. I find that process to be tedious and no fun at all, so I'm not going to spent my free time on it. Should nobody else step up to act as a release manager for those releases, they will be unsupported. Are you a new Andreas? Nobody can replace Andreas and the tremendous amount of time and dedication he has shown. Personally I do not care about evangelizing Zope2 or helping out end-users on mailing lists amongst others. So no, I'm not going to do all the work Andreas did. I'm only here to help out as a release manager, whose job it is to get stable releases out. I do read the developers mailing lists and watch the bug trackers, I don't read any users mailing list or see it as my job to fix or respond to every bug anyone reports. What about that Plone release manager position? I am currently the release manager for Plone 5. We have clarified the overall roadmap for Plone 5, and we aren't going to work on any of the formal release parts for the next 12 months or longer. The current focus is on the Plone 4.x release series, where Eric Steele serves as the release manager. So while I'm going to keep my post as a Plone release manager, it currently doesn't involve any time commitments. What about Zope 2.14 or beyond? Nobody knows yet. We will see once we get there. My formal commitment is for 2.12 and 2.13. Are you insane? Maybe a little bit. But seriously if anyone knows anyone else who would be interested in this job, speak up. I haven't seen anyone else since Andreas stepped down. And I happen to work for a company which is 100% dependent on Zope / Plone for their income stream. While I'm doing this in my spare time, I do have a very real need for Zope2 releases. I'm planning to make a 2.12.4 release on Easter Monday (April 5). You have until then to ask questions and complain :) Hanno

10 19

Re: [Zope-dev] Zope 2.13 roadmap
by Hanno Schlichting 01 Apr '10

01 Apr '10

On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <optilude+lists(a)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. - 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. - 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 :) - 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. - 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. - 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. - 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. - 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. - Python 3.x Not on the agenda. We'll need to tackle this on the ZTK level first. 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. 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. Cheers, Hanno

5 10

Summary of this weeks' meeting (2010-03-30)
by Christian Theune 01 Apr '10

01 Apr '10

Hi, here's this week's summary. For those of you who can't/don't participate in those meetings, there's the open question about how useful you consider my summaries to be. Please tell! Also in short: we decided to keep going with the meetings, so I'd be happy to see you guys next week in #zope. (Hopefully without screwing up the time then.) Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

12 12

Zope Tests: 6 OK, 1 Unknown
by Zope Tests Summarizer 01 Apr '10

01 Apr '10

Summary of messages to the zope-tests list. Period Wed Mar 31 12:00:00 2010 UTC to Thu Apr 1 12:00:00 2010 UTC. There were 7 messages: 6 from Zope Tests, 1 from ct at gocept.com. Unknown ------- Subject: FAILURE: Repository policy check found errors in 715 projects From: ct at gocept.com Date: Wed Mar 31 10:27:29 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013834.html Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 31 21:29:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013835.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 31 21:31:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013836.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 31 21:33:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013837.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 31 21:35:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013838.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 31 21:37:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013839.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 31 21:39:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013840.html

1 0

IAbsoluteURL for browser view should contain @@?
by Christian Zagrodnick 01 Apr '10

01 Apr '10

Hi, the explicit way to address a view is using the /@@viewname namespace traversal. An IAbsoluteURL for a browser view returns an URL without the @@ (i.e. /foo/bar/view instead of /foo/bar/@@view). I think this should be changed so that the URL contains the @@. If you agree with this, where should I place this adapter? The two relevant interfaces are zope.browser.interfaces.IBrowserView zope.traversing.browser.interfaces.IAbsoluteURL But neither package depends on the other, so a different package might be more suiteable? Regards, -- Christian Zagrodnick · cz(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development

3 3

Zope2: Reducing C dependencies
by Hanno Schlichting 01 Apr '10

01 Apr '10

Hi. For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of the Zope2 distribution itself. Ideally it would not have any C dependencies in its own distribution, but that's a bit too much for now. As a next step I'd like to split out the initgroups, Missing, MultiMapping, Record and ThreadLock packages into their own distributions. The code in these hasn't changed in years and I don't see this changing anytime soon. If this is done the remaining C libraries are in AccessControl, DocumentTemplate and ZCTextIndex. AccessControl has a reference implementation in Python and could the C library could be made an optional optimization. The ZCTextIndex okascore.c and stopper.c should also be relatively easy to do as Python implementations. DocumentTemplate has a pDocumentTemplate.py module as a reference implementation, which clearly states that it is outdated. This would need to be updated to match the C implementation. Hanno

6 15