Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
In this case, the answer is clear to me. :) We should fix the offending Z3 code to match the interface. Similarly, we should fix the uses of get_transaction. Jim Tim Peters wrote: I'm merging ZODB 3.4 into Zope on a branch. As Tres noted earlier in a checkin comment, a test failure results, because at the ZODB sprint we fleshed out IDataManager and an older Zope3 class claiming to implement IDataManager no longer does. Since Zope trunk doesn't own either the IDataManager definition nor the old Zope3 code, it's unclear how best to proceed: ERROR: testInterface (zope.app.mail.tests.test_delivery.TestMailDataManager) -- Traceback (most recent call last): File C:\Code\Zope\lib\python\zope\app\mail\tests\test_delivery.py, line 46, in testInterface verifyObject(IDataManager, manager) File C:\Code\Zope\lib\python\zope\interface\verify.py, line 93, in verifyObject return _verify(iface, candidate, tentative, vtype='o') File C:\Code\Zope\lib\python\zope\interface\verify.py, line 60, in _verify raise BrokenImplementation(iface, n) BrokenImplementation: An object has failed to implement interface InterfaceClass transaction.interfaces.IDataManager The abort_sub attribute was not provided. An expedient hack would be to castrate ZODB 3.4's IDataManager definition, back to what it was before the ZODB sprint. That's unattractive for obvious reasons (like, e.g., that the old definition lied about what the interface actually is). Current Zope3 trunk will have the same problem with ZODB 3.4 in its MailDataManager class, so that's the right place to fix it. But then the repaired version also needs to be merged into the old Zope3 code Zope trunk is trying to use. The old zope/app/mail/delivery.py also uses the deprecated get_transaction(). Perhaps current Zope3 trunk's delivery.py could just be slammed into the tag used by (or a new tag created for) Zope trunk? get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Martijn Faassen wrote: Tim Peters wrote: [snip] get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. The new ZODB version is having some repercussions there. Zope X3.0 was released against an older version of ZODB. I'm really at a loss at what to do there. Perhaps we should make a X3.0.1. This is fairly long overdue anyway. Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. I can spend time trying to shut up Zope X3 I guess, if that is the only option... I think this is the best option. What is the recipe of changing get_transaction(), is this documented somewhere? It should be documented in the deprecation warning. Basically, rather than: get_transaction().commit() you should: import transaction ... transaction.commit() or from transaction import commit ... commit() Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
[Tim Peters] ... get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). [Martijn Faassen] Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. I know. That's why I pushed and pushed to get the branch merged early -- I knew _something_ would go wrong, I just didn't know what wink. Jim and I knew about the ZODB-3.4-in-Zope-2.8 plans for quite a while, but I doubt that even Brian was aware of them. There's no way you could have known -- not your fault. The new ZODB version is having some repercussions there. Zope X3.0 was released against an older version of ZODB. I'm really at a loss at what to do there. I can spend time trying to shut up Zope X3 I guess, if that is the only option... What is the recipe of changing get_transaction(), is this documented somewhere? It is, but it would go faster if I did it. I rewrote all uses of get_transaction() in the Zope and Zope3 trunks on Monday, so I'm in practice. For the most part they amount to no more than what Jim said, but there are trickier cases than commit(). Suggestion: I make a new copy of Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1/src/zope stitch that into Zope trunk (change the lib/python svn:externals to point to the new copy), do all the get_transaction() edits there, and repair the IDataManager glitch there too. This could easily be done before lunch today (my time wink). If people are agreeable, help me pick a name for the new copy; I have no idea what the pr1 is supposed to mean in the current name, but would like to stick to whatever naming convention is in use there. I don't think Five has much in the way of fundamental get_transaction(); ... That's right -- it's almost all under lib/python/zope/. [Jim Fulton[ Perhaps we should make a X3.0.1. This is fairly long overdue anyway. Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. Above, I'm volunteering to do the latter. Somehow I get the impression that sticking an unplanned X3.0.1 release on the critical path for Zope 2.8 wouldn't go over well here wink. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
[Tim Peters] ... Suggestion: I make a new copy of Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1/src/zope stitch that into Zope trunk (change the lib/python svn:externals to point to the new copy), do all the get_transaction() edits there, and repair the IDataManager glitch there too. This could easily be done before lunch today (my time wink). I assume nobody objects, since nobody objected ahem. I see that Zope3/branches/ZopeX3-3.0.0-Zope-2.8 already exists, has already made changes to Zope3 code, and that the Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1 tag Zope trunk is currently using appears to be a tag made off of that branch. So I'll continue on that line: make edits in Zope3/branches/ZopeX3-3.0.0-Zope-2.8 and, when they're done, make a new tag from that branch and stitch the new tag into Zope trunk. If anyone objects, please do so ASAP. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Jim Fulton wrote: Martijn Faassen wrote: Tim Peters wrote: [snip] get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. The new ZODB version is having some repercussions there. Zope X3.0 was released against an older version of ZODB. I'm really at a loss at what to do there. Perhaps we should make a X3.0.1. This is fairly long overdue anyway. I'll see whether I can make some time to go through X3.0. in that case, to prepare for a X3.0.1. To do this work, I need ZODB 3.4 to be stitched into here, right: http://svn.zope.org/Zope3/branches/ZopeX3-3.0/ is there a resolution on how to do this yet? Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. It's probably better to do it on X3.0 branch proper, and then extract a new 'more minimal' branch for Zope 2.8 (which we already have). It would be best if Tres did the latter, as he did it last time. :) We need to carefully check whether there aren't changes in ZopeX3.0 for Zope 2.8 that we need to port to the new branch. Perhaps Tres has an idea on how to approach all of this. I can spend time trying to shut up Zope X3 I guess, if that is the only option... I think this is the best option. What is the recipe of changing get_transaction(), is this documented somewhere? It should be documented in the deprecation warning. Thanks; I haven't seen those warnings yet as I don't think ZODB 3.4 quite got merged into Zope 2.8 trunk yet. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Tim Peters wrote: [Tim Peters] ... get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). [Martijn Faassen] Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. I know. That's why I pushed and pushed to get the branch merged early -- I knew _something_ would go wrong, I just didn't know what wink. But it isn't going wrong, as ZODB 3.4 is there yet, right? :) We only find out because you tried it on some other branch? I'm not clear on where this went on... [snip] Suggestion: I make a new copy of Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1/src/zope If we're going to go that route, no need to make a copy, just use the branch that's already there for exactly this purpose: http://svn.zope.org/Zope3/branches/ZopeX3-3.0.0-Zope-2.8/ and make a new -pr2 or -integration2 or whatever you like tag out of it when you're done. stitch that into Zope trunk (change the lib/python svn:externals to point to the new copy), do all the get_transaction() edits there, and repair the IDataManager glitch there too. This could easily be done before lunch today (my time wink). Just stitch back in the /branches/ZopeX3-3.0.0-Zope-2.8, and fix that, and then, when you're done, copy it to a new tag and update the external to that. If people are agreeable, help me pick a name for the new copy; I have no idea what the pr1 is supposed to mean in the current name, but would like to stick to whatever naming convention is in use there. Right, pr1 is out of date. What about? Zope3/tags/ZopeX3-3.0.0-Zope-2.8-i2 for 'integration 2'? :) [snip] Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. Above, I'm volunteering to do the latter. Somehow I get the impression that sticking an unplanned X3.0.1 release on the critical path for Zope 2.8 wouldn't go over well here wink. Geez, that's true, thanks. :) I'm too addled today to even yammer about it a lot. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Tim Peters wrote: [Tim Peters] ... Suggestion: I make a new copy of Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1/src/zope stitch that into Zope trunk (change the lib/python svn:externals to point to the new copy), do all the get_transaction() edits there, and repair the IDataManager glitch there too. This could easily be done before lunch today (my time wink). I assume nobody objects, since nobody objected ahem. I see that Zope3/branches/ZopeX3-3.0.0-Zope-2.8 already exists, has already made changes to Zope3 code, and that the Zope3/tags/ZopeX3-3.0.0-Zope-2.8-pr1 tag Zope trunk is currently using appears to be a tag made off of that branch. So I'll continue on that line: make edits in Zope3/branches/ZopeX3-3.0.0-Zope-2.8 and, when they're done, make a new tag from that branch and stitch the new tag into Zope trunk. If anyone objects, please do so ASAP. This is exactly right! I should read all your mail, I'm typing at cross-purposes. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
[Martijn Faassen, on deprecation warnings] Thanks; I haven't seen those warnings yet as I don't think ZODB 3.4 quite got merged into Zope 2.8 trunk yet. Not even close yet. I'm doing the 3,4 integration work on Zope/branches/tim-merge-zodb34 and I'm not merging anything into the trunk until all the ZODB 3.4 integration issues are settled on that branch. Jim also wants to make changes to ZODB 3.4. And I need to make more changes to ZODB 3.4 too. In an ideal world, the five-integration branch would have been merged to the trunk during the PyCon week, and then all this later work could have started on Monday. As is, it didn't really start until last night. But from my POV, it's under control wink. I expect that the alpha2 release needs to slip until early next week, though. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Zope trunk is using ZODB 3.4 now. It's been switched to use svn:externals to stitch in the 9 ZODB directories. For now they're pointing at ZODB trunk. A release tag will be made later (this is _not_ ready for release yet; now I can start doing the work I wanted to start doing on Monday 0.5 wink). The Zope3 code is now gotten from new tag Zope3/tags/ZopeX3-3.0.0-Zope-2.8-a2. That code was purged of get_transaction() calls, and the IDataManager glitch got repaired there. If that code needs more changes, they should be made on Zope3/branches/ZopeX3-3.0.0-Zope-2.8, another tag made from the result, and the lib/python properties changed to point to that tag. Really helpful: you can do svn propedit followed by svn up to _temporarily_ redirect your local copy to a different source for svn:externals. If you svn revert the propedit changes before a commit, nobody else will be affected. A handful of get_transaction() calls were also removed from the Five code. Zope's setup.py got taught how to build ZODB 3.4's new IFBTrees. All tests should pass on Linux (the same two still fail on Windows). There should be no DeprecationWarnings related to transactions. I'm not sure svn will do a decent job of updating. We're simultaneously trying to delete Zope trunk's *copies* of ZODB code, and stitch the same things (well, directories of the same names) back in via svn:externals. At one point during the Zope/branches/tim-merge-zodb34 merge on my local box, svn got itself terminally confused, starting to create directories like lib/lib/python/ZODB (there are two lib/s in that -- not a typo), and griping endlessly about locks and non-existent files. No amount of svn cleanup could repair it, and I ended up checking out Zope trunk from scratch again. Then all the problems went away. If people have trouble updating on Linux, say so here, and we can share solutions. I hope that I hit problems just because I was doing the merge. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
| At one point during the Zope/branches/tim-merge-zodb34 merge on my | local box, svn got itself terminally confused, starting to create | directories like lib/lib/python/ZODB (there are two lib/s in that -- | not a typo), and griping endlessly about locks and non-existent files. | No amount of svn cleanup could repair it, and I ended up checking | out Zope trunk from scratch again. Then all the problems went away. | | If people have trouble updating on Linux, say so here, and we can | share solutions. I hope that I hit problems just because I was doing | the merge. Got one problem so far: svn: Failed to add directory 'lib/python/BTrees/tests': object of the same name already exists Everything else seems to have updated with no problems to that point. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher I have not yet begun to byte! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
[Sidnei da Silva] Got one problem so far: svn: Failed to add directory 'lib/python/BTrees/tests': object of the same name already exists Everything else seems to have updated with no problems to that point. Ugh -- I'm afraid that's the very first of the 9 ZODB directories it tried to update, and svn just isn't smart enough to delete the existing directories before trying to fetch the new ones. Did you find a way to work around that (short of checking out Zope from scratch? the latter works fine, but is irritating)? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
On Thu, Mar 31, 2005 at 03:33:11PM -0500, Tim Peters wrote: | Ugh -- I'm afraid that's the very first of the 9 ZODB directories it | tried to update, and svn just isn't smart enough to delete the | existing directories before trying to fetch the new ones. Indeed it was. I think its a Good Thing. Explicitness. | Did you find a way to work around that (short of checking out Zope | from scratch? the latter works fine, but is irritating)? Removing the only the complainers and svn up after that. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
I'm merging ZODB 3.4 into Zope on a branch. As Tres noted earlier in a checkin comment, a test failure results, because at the ZODB sprint we fleshed out IDataManager and an older Zope3 class claiming to implement IDataManager no longer does. Since Zope trunk doesn't own either the IDataManager definition nor the old Zope3 code, it's unclear how best to proceed: ERROR: testInterface (zope.app.mail.tests.test_delivery.TestMailDataManager) -- Traceback (most recent call last): File C:\Code\Zope\lib\python\zope\app\mail\tests\test_delivery.py, line 46, in testInterface verifyObject(IDataManager, manager) File C:\Code\Zope\lib\python\zope\interface\verify.py, line 93, in verifyObject return _verify(iface, candidate, tentative, vtype='o') File C:\Code\Zope\lib\python\zope\interface\verify.py, line 60, in _verify raise BrokenImplementation(iface, n) BrokenImplementation: An object has failed to implement interface InterfaceClass transaction.interfaces.IDataManager The abort_sub attribute was not provided. An expedient hack would be to castrate ZODB 3.4's IDataManager definition, back to what it was before the ZODB sprint. That's unattractive for obvious reasons (like, e.g., that the old definition lied about what the interface actually is). Current Zope3 trunk will have the same problem with ZODB 3.4 in its MailDataManager class, so that's the right place to fix it. But then the repaired version also needs to be merged into the old Zope3 code Zope trunk is trying to use. The old zope/app/mail/delivery.py also uses the deprecated get_transaction(). Perhaps current Zope3 trunk's delivery.py could just be slammed into the tag used by (or a new tag created for) Zope trunk? get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: --On Samstag, 19. März 2005 18:15 Uhr +0100 Martijn Faassen [EMAIL PROTECTED] wrote: No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed. I have update the 2.8 wiki with the planned release schedule. Thanks! Looks good. I'll commit some time to make this work. [snip] We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested. You are arguing with the Z3/Five hat on. Having a reliable Zope 2.8 version with MVCC support is much more important to most people than having a perfect Five support. So the primary goal of the Zope 2.8 release is to have a stable successor release for Zope 2.7. True, MVCC is important and MVCC needs to be tested, but I believe unfortunately the best test for it will be in real world production use, and a release will happen before most people risk that... I believe you'll find it interesting that there was a sprint full of people who were motivated to hack on Zope 2.8 because of the Zope 3 aspect, not the MVCC aspect. I myself proposed several times early in the week to go without Five, but people objected. I know I'm hard to trust as a source of this, as I have the 'Five hat' on, but it's so anyway. :) I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed. I hope everyone is really commited. We'll see how far we can get with this approach. I definitely hope people are indeed committed too. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
--On Samstag, 19. März 2005 18:15 Uhr +0100 Martijn Faassen [EMAIL PROTECTED] wrote: No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed. I have update the 2.8 wiki with the planned release schedule. I'd prefer a shorter cycle, with an alpha 2 this month, a beta in april, and a release at the latest in may. I would also very much like to have a release date set and committed to. I don't like to hear hopefully a final version in Q2 and such estimates in relation to Zope releases; it almost *invites* further delays. The latest delays are basically caused by missing contributions from the community. Since 2.8a1 in October 2004 most fixes were made by Tim, Jim, Stefan Holek and myself. We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested. You are arguing with the Z3/Five hat on. Having a reliable Zope 2.8 version with MVCC support is much more important to most people than having a perfect Five support. So the primary goal of the Zope 2.8 release is to have a stable successor release for Zope 2.7. I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed. I hope everyone is really commited. We'll see how far we can get with this approach. Andreas pgpRCKCJ9HXLy.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas, thanks for your efforts Robert ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
--On Freitag, 18. März 2005 12:31 Uhr -0500 Jim Fulton [EMAIL PROTECTED] wrote: A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality. I don't think we have new features on the to do list. These are all bug fixes or optimizations. My point is: we are adding a lot of new code to the Zope 2 core - it does not matter if there is a tight or a loose coupling between Z2 and Z3 - and calling it beta. Any code going into a beta should have been tested within at least one alpha release. In my opinion alpha releases have the task to figure out major integration problems. Such problems should be solved before the beta cycle. My fear is that we are running into the same release problems as with the Plone 2.0 release (lots of development and changes during the beta phase). My suggestion: let's make an Zope 2.8 alpha 2 in the first week of April and let us nail down a release date for beta 1 (in early May). So there is enough time for interested people to test the Z3 integration and for others to fix outstanding issues in the Zope 2 core. This gives everyone (I have the Plone, CPS, Silva communities in mind) the possibility to check out if there is something missing in Zope 2.8 *before* we are going into a *short* beta release cycle with hopefully a final version in Q2. Any comments? Andreas pgpxff4mmemuu.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: --On Freitag, 18. März 2005 12:31 Uhr -0500 Jim Fulton [EMAIL PROTECTED] wrote: A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality. I don't think we have new features on the to do list. These are all bug fixes or optimizations. My point is: we are adding a lot of new code to the Zope 2 core - it does not matter if there is a tight or a loose coupling between Z2 and Z3 - and calling it beta. Any code going into a beta should have been tested within at least one alpha release. In my opinion alpha releases have the task to figure out major integration problems. Such problems should be solved before the beta cycle. My fear is that we are running into the same release problems as with the Plone 2.0 release (lots of development and changes during the beta phase). My suggestion: let's make an Zope 2.8 alpha 2 in the first week of April and let us nail down a release date for beta 1 (in early May). So there is enough time for interested people to test the Z3 integration and for others to fix outstanding issues in the Zope 2 core. This gives everyone (I have the Plone, CPS, Silva communities in mind) the possibility to check out if there is something missing in Zope 2.8 *before* we are going into a *short* beta release cycle with hopefully a final version in Q2. Any comments? I think this makes a lot of sense. Of course, it's up to you and Brian. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Brian Lloyd wrote: Hi all, There have been a number of threads going on today re: Zope X3.1 feature freeze and the 2.8 effort. I'd like to clarify some decisions re: Zope 2.8 Jim is the product mgr for Zope 3 and I'm it for Zope 2, so hopefully this can be considered authoritative and end part of this thread ;) Absolutely - Zope 2.8 will include X3.0 (not X3.1) - The Z3 developers will have *no* extra burden or responsibility to support X3.0 beyond what they would normally do in the normal course of maintaining it for Z3-only applications. In other words, it is not the responsibility of Z3 devs to make sure Z2 tests pass, etc. I think this is a reasonable compromise. ... - As a community, we will work out how best to adapt the Zope 2 release process and schedule to that of Zope 3 going forward. We don't need to decide this immediately to continue to make progress on 2.8. I suggest an IRC meeting sometime soon to draft a proposal. I would like to see the Zope 2, Zope 3, and ZODB release cycles combined, at least for feature (dot zero) releases, starting with Zope 2.9 and X3.2. That is, I'd like them to have the same release cycle. These should, of course, be time-based releases. My preference is for every 6 months, but I'm more than willing to try 4. My worry is that if the cycles are too short, there will be inadequate time for alpha and beta releases. Plus, a 6-month cycle would allow us to say that deprecated features will be supported for a year. (Of course, we could do that anyway if we supported 3 releases instead of 2.) Thanks Brian! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: [snip] I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8.. A beta release should be feature-complete means it should contain everything that will be part of the final release. Are optimizations a feature? I guess so. :) A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality. Alpha 2 is fine with me, and I think most people of the sprint agreed. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: [snip] My point is: we are adding a lot of new code to the Zope 2 core - it does not matter if there is a tight or a loose coupling between Z2 and Z3 - and calling it beta. [snip] My fear is that we are running into the same release problems as with the Plone 2.0 release (lots of development and changes during the beta phase). I think it does matter that we're not creating new code, but loosely integrating code that already exists, used, and, mostly, has already been released. I think that's quite different from what you describe was a problem with the Plone 2.0 release. No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed. [snip] My suggestion: let's make an Zope 2.8 alpha 2 in the first week of April and let us nail down a release date for beta 1 (in early May). So there is enough time for interested people to test the Z3 integration and for others to fix outstanding issues in the Zope 2 core. This gives everyone (I have the Plone, CPS, Silva communities in mind) the possibility to check out if there is something missing in Zope 2.8 *before* we are going into a *short* beta release cycle with hopefully a final version in Q2. Any comments? I'd prefer a shorter cycle, with an alpha 2 this month, a beta in april, and a release at the latest in may. I would also very much like to have a release date set and committed to. I don't like to hear hopefully a final version in Q2 and such estimates in relation to Zope releases; it almost *invites* further delays. We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested. I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed. I would also like to refer you to the Linux kernel, where release candidates are rarely tested, and the real bugs come out with production releases. I think that's also a reality for Zope. The core Plone, Silva and CPS developers present at the sprint also expressed a strong preference for getting this into production quickly. There will be bugs in Zope 2.8, but a Zope 2.8.1 release should be relatively easily made if that's the case. There are some resources available to make this release happen on time. I'll commit a bit of my time, and I trust the others who worked on this at the sprint will chip in as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Clarification re: Zope X3.1, 2.8
Hi all, There have been a number of threads going on today re: Zope X3.1 feature freeze and the 2.8 effort. I'd like to clarify some decisions re: Zope 2.8 Jim is the product mgr for Zope 3 and I'm it for Zope 2, so hopefully this can be considered authoritative and end part of this thread ;) - Zope 2.8 will include X3.0 (not X3.1) - The Z3 developers will have *no* extra burden or responsibility to support X3.0 beyond what they would normally do in the normal course of maintaining it for Z3-only applications. In other words, it is not the responsibility of Z3 devs to make sure Z2 tests pass, etc. - It *will be* the responsibility of the Zope 2 devs to make sure Z2 works with the version of Z3 bundled at the time. - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. - Anyone who cant wait for that can use the five-integration branch in SVN - As a community, we will work out how best to adapt the Zope 2 release process and schedule to that of Zope 3 going forward. We don't need to decide this immediately to continue to make progress on 2.8. I suggest an IRC meeting sometime soon to draft a proposal. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
--On Freitag, 18. März 2005 11:22 Uhr -0500 Brian Lloyd [EMAIL PROTECTED] wrote: - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release: - Renable C permission roles by implementing recent Python changes in C, brining the Python and C implementations back in sync. See lib/python/AccessControl/PermissionRole.py. - Add cyclic-garbage collection support to C extension classes, especially to acquisition wrappers. - Change acquisition wrappers to implement the descr get slot directly, thus speeding the use of the slot. - Renable C Zope security policy by implementing recent Python changes in C, brining the Python and C implementations back in sync. See lib/python/AccessControl/ZopeSecurityPolicy.py. Andreas pgpripUiYaasx.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
On Fri, Mar 18, 2005 at 11:22:26AM -0500, Brian Lloyd wrote: [snip] - Zope 2.8 will include X3.0 (not X3.1) - The Z3 developers will have *no* extra burden or responsibility to support X3.0 beyond what they would normally do in the normal course of maintaining it for Z3-only applications. In other words, it is not the responsibility of Z3 devs to make sure Z2 tests pass, etc. - It *will be* the responsibility of the Zope 2 devs to make sure Z2 works with the version of Z3 bundled at the time. - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. - Anyone who cant wait for that can use the five-integration branch in SVN Which is now as ready as we'll make it at this sprint. There are still a few loose ends (in particular we may want to synch up a few packages like zconfig and restructured text if it isn't too difficult), though those ends are not strictly necessary for Five support. - As a community, we will work out how best to adapt the Zope 2 release process and schedule to that of Zope 3 going forward. We don't need to decide this immediately to continue to make progress on 2.8. I suggest an IRC meeting sometime soon to draft a proposal. Thanks on behalf of the sprinters here working on this! I hope we can all gather in the IRC meeting. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Brian Lloyd wrote: Hi all, There have been a number of threads going on today re: Zope X3.1 feature freeze and the 2.8 effort. I'd like to clarify some decisions re: Zope 2.8 Very much excellent! This, Jims announcement of the April 2 feature freeze datem and Stephans statement that he was mostly finished wih thhis X3. work makes this a day of many promising emails. ;) I was a bit surprised at seeing a feature freeze I had assumed had happened being announced, but after pondering it I realize it's fine. And with Pycon coming up, April 2 is probably a good date as well. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
On Fri, Mar 18, 2005 at 05:42:05PM +0100, Andreas Jung wrote: --On Freitag, 18. M?rz 2005 11:22 Uhr -0500 Brian Lloyd [EMAIL PROTECTED] wrote: - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release: [snip todos] I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8.. Do some of these have something to do with a change to Python 2.4, by the way? It's a bit unclear to me what version of Python this release is targetting. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
--On Freitag, 18. März 2005 18:03 Uhr +0100 Martijn Faassen [EMAIL PROTECTED] wrote: On Fri, Mar 18, 2005 at 05:42:05PM +0100, Andreas Jung wrote: --On Freitag, 18. M?rz 2005 11:22 Uhr -0500 Brian Lloyd [EMAIL PROTECTED] wrote: - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release: [snip todos] I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8.. A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality. Andreas pgpJjW0QpGB5V.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Martijn Faassen wrote: ... Do some of these have something to do with a change to Python 2.4, by the way? No. It's a bit unclear to me what version of Python this release is targetting. 2.3 Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: --On Freitag, 18. März 2005 18:03 Uhr +0100 Martijn Faassen [EMAIL PROTECTED] wrote: On Fri, Mar 18, 2005 at 05:42:05PM +0100, Andreas Jung wrote: --On Freitag, 18. M?rz 2005 11:22 Uhr -0500 Brian Lloyd [EMAIL PROTECTED] wrote: - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release: [snip todos] I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8.. A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality. I don't think we have new features on the to do list. These are all bug fixes or optimizations. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
[Martijn Faassen] ... Do some of these have something to do with a change to Python 2.4, by the way? [Jim Fulton] No. If you're using the Python 2.4 line, some of the security changes triggered a Python bug that will be fixed in 2.4.1 (which is currently in release candidate 2 status). It's a bit unclear to me what version of Python this release is targetting. 2.3 There are relevant (but different) Python bugs in 2.3 too. I'd say = 2.3.4 is the requirement now. I only test with 2.3.5. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
