[Zope-dev] direction
Hi, this is my first posting on the list, so please be kind if i make some mistakes ;-) On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida leorochael at gmail.com wrote: I noticed you've been very busy doing clean-up on the Zope2 code base in the last few hours. As someone who has recently spent a lot of time porting forward a large and mission-critical code base, ERP5, from Zope 2.8 to Zope 2.12, I'm a little confused about the direction that you're moving, and how much effort that could mean for future porting efforts for Nexedi. I think moving to Zope 2.12 and 2.13 does have some value for Nexedi or other large existing codebases, as you get support for current versions of the ZODB, Zope Toolkit packages and support for Python 2.7 with Zope 2.13. Since Python 2.7 is a long-term maintenance release for Python itself, this should provide a stable and good basis for the next years - the statements from the Python community aren't completely clear - but I'd expect to see ongoing maintenance until 2013 or maybe even 2015. Going forward I can see two paths for Zope 2. Either we don't touch it at all anymore and let it bitrot or we try to move it forward and adept it to current best practices of development. Since complete rewrites almost always fail, like we have seen with Zope 3 - I prefer changing Zope 2. I agree with you. Evolution is better then revolution. If you are interested in stability I think sticking with an older version of Zope 2 is a completely sane and good approach. OK, so you do think that we might use Zope 2.12 for a quite long time without thinking about anymore updates? Will there be any security updates for Zope 2.12 in the future? What me and others from the Plone community are trying to do with the Zope 2 codebase is to actually move it forward. We can either do that as part of the official Zope 2 release series or fork the codebase. Since so far there isn't really anyone else interested in working on the Zope 2 codebase, we keep changing Zope 2 without forking it. Unfortunately i am not really able to help or work on the codebase, but we are using Zope 2.x for several years now. But can you explain to us a little of how you expect Zope2 to behave with the changes you're doing? There's a number of things I want to do. Not sure when I'll or others will have the time, but these are things I expect to happen in the next months or releases: - Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI OK, we're not using any of the stated functionality, but what is the reason for removing most of the ZMI? - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon We are using the virtual host monster (at least one per instance), we are using the error_log as well in all our applications. Are there any alternatives already? - Make the browser id manager, session data manager, temporary storage optional and remove it and request.SESSION from the core, instead we can use something based on Products.BeakerSessionDataManager / collective.beaker if someone has a need for sessions Hmm, i am not that much into Zopes structure, but if we are using request.SESSION we are in the need of the browser id manager, the session data manager and the temporary storage as well, right? - Start using and storing parent pointers and remove Acquisition.Implicit from the most common base classes (a branch for this already exists with almost all core tests passing) Does this mean, if i want to use a DTML method in a folder structure like this: /a/b/c/d/e i will have to know which level the method exists? We are using a lot of methods stored in folder a but used from folder b to e... Or can you give me a short explanation about what Acquisition.Implicit does? - Merge five.pt (Chameleon) into the core and use it instead of the zope.tal/zope.tales implementation (which means no more RestrictedPython for templates) - Once most of the ZMI is gone, it should be feasible to drop DTML or rewrite what little is left as page templates Now i am completely shocked. We are building web applications for the last 6 years in Zope 2.x. All those applications are using the following techniques: - DTML method/document - Z MySQL Database Connection and Z SQL Method - MailHost / MailDrop Host - RAM Cache Manager - acl_users User Folder - Script (Python) - External Method - error_log - File, Image, ExtFile and ExtImage - REQUEST / REQUEST.SESSION - Virtual Host Monster - Browser Id Manager - Session Data Manager / Session Data Container - Temporary Folder This would mean to migrate at least one hundred projects from DTML to TAL/ZPT? Please, what is this all about? If i read the following:
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@know-it.net wrote: OK, so you do think that we might use Zope 2.12 for a quite long time without thinking about anymore updates? Will there be any security updates for Zope 2.12 in the future? You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports). Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release. How long Zope 2.13 is going to be supported and sees security fixes will depend on the community. The Plone community will use it for its 4.1 and 4.2 releases, as a result of our security policy that should result in us supporting Zope 2.13 for the next two years. Beyond that nobody knows what will happen. Now i am completely shocked. We are building web applications for the last 6 years in Zope 2.x. All those applications are using the following techniques: [snip] What you are describing is exactly what I meant by old legacy Zope2 applications. You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Mon, Jul 4, 2011 at 10:49 AM, Sylvain Viollon sylv...@infrae.com wrote: ... and I still do use the VirtualHostMonster (you can trash all the other things). I agree that its code might not been the best in the world, but it works for the moment and does what it says (I would love to see shiftNameToApplication implemented with more than one pass). Ok. I didn't mean to remove the VHM at any point. I removed it from the default content over the weekend but given its popularity, I think I can safely put it back. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 5 July 2011 09:42, Hanno Schlichting ha...@hannosch.eu wrote: What you are describing is exactly what I meant by old legacy Zope2 applications. You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point. I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? Martin ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com wrote: I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. I think it might be useful to spell out the reasons behind this (here, or better yet, somewhere more permanent like zope.org). I can imagine people reading this and wondering why it's a good idea, especially those who have an investment in the existing technologies. Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end. This is a pretty sweeping statement that I think could cause a lot of nervousness. It might be the right thing in many ways, but we need to at least provide a bit more context. If you're a business that's invested dozens of person-years into a product, the prospect of rewriting could seem fairly daunting. At least we, as the Zope 2 community, need to set out the case for change and some kind of idea of timing and transition path, even if that means in some cases getting to a long term maintenance release and in other cases evolving away from certain technologies whilst being confident to keep using others. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote: Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years. Yes. I'm willing to cut releases for it for quite a while. I just expect to see active maintenance from the Plone community to stop in a year or two. Judging from the ongoing maintenance we currently have for Zope 2.10 or 2.11 I don't think it's very realistic to expect much to happen once the Plone guys stop. What I'm outlining here has of course almost nothing to do with the original idea and scope of Zope 2. Maybe at some point this should get a different name ;-) I don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release. I think that's perfectly fine. Since I broke backwards compatibility with a number of changes I did, a major version increase is warranted. So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote: Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years. Yes. I'm willing to cut releases for it for quite a while. I just expect to see active maintenance from the Plone community to stop in a year or two. Judging from the ongoing maintenance we currently have for Zope 2.10 or 2.11 I don't think it's very realistic to expect much to happen once the Plone guys stop. What I'm outlining here has of course almost nothing to do with the original idea and scope of Zope 2. Maybe at some point this should get a different name ;-) I don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release. I think that's perfectly fine. Since I broke backwards compatibility with a number of changes I did, a major version increase is warranted. So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. I actually think it's a brilliant idea to skip 3.0 and call it 4.0. As Martin said, the potential for confusion is very high. A 4.0 would not only steer around confusing Zope3 3.x and Zope2 3.x, it would also make it easier to move back to the simple Zope moniker without any qualifying number tacked on. People who only look at version numbers would now choose Zope 4.0 instead of falling into the unmaintained Zope3 trap. jens ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 5 July 2011 11:10, Jens Vagelpohl j...@dataflake.org wrote: On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. I actually think it's a brilliant idea to skip 3.0 and call it 4.0. As Martin said, the potential for confusion is very high. A 4.0 would not only steer around confusing Zope3 3.x and Zope2 3.x, it would also make it easier to move back to the simple Zope moniker without any qualifying number tacked on. People who only look at version numbers would now choose Zope 4.0 instead of falling into the unmaintained Zope3 trap. I would tend to agree, given that we now have Blue Bream. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2011 12:04, schrieb Hanno Schlichting: On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places. I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions. Greetings, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEuXYAAoJEFJi5/9JEEn+JS0QALwzhuqnNvVzngKpEiDRIPmG SIbAlbvUHIOb15kZCWCZlJjvmIuwHd2eQdbKScit7o/WBNzH38L5+BGoWPZil0k6 X04WmaXd/15OfWtGGkwsxG8Jt9gO5b6kvyu9a54qVdiNpHs9M5531XvCcPFyG9yY FLdmkRUMtpATg7o0YLt2B5lKWnojDvVvVgTXy8ad/UhO6TKrNzySRHLPiOhnh9LY 7axX/ExErzU9CFPB02joKP140ex5Om72L66FXWVNNZ9GUVaIT0puOTxLnbfkSahl TeItFjzby4xdQ89ot5OD7nlMgvuPx0Scstuf+GaQH60xoTDj8EIQEwoSotDYMUSD GHqD3eGsn1ORgB2ov/7dUW9xaEkLHfu7ikLozGXnD2xtGXTZG7tjuagmusV9Mftj kRjoCrSAAz8KM4FnAeLxdgYHIIEN3KRkJXeyqAMtcOoCgRZFEWILJWxcoU2CbYP9 4WAeQlnWby5KgUS+rSiJ7zLRu0uas4gAKb513jt1KJDOFSmzVQECrpQJ3bHvykK7 uVj+00/smgPk/DnCLlJTHuZwQVDEFmAtjOd31lreTHAFE46BHmbjSYMFXIHI01D4 4H4AiXlnb2BS55wH+JvmdM1+j8IkgaBI6LBtBCotpcZXSAv4/BXvCm2Ynwte/yXU GlwhHtBmyZ6HfdhuVrUI =Cir1 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
Hi Hanno On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@know-it.net wrote: OK, so you do think that we might use Zope 2.12 for a quite long time without thinking about anymore updates? Will there be any security updates for Zope 2.12 in the future? You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports). Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release. OK, thx for the info. So we will be able to use Zope 2.13 with the techniques mentioned before? That will give us another two years to think about going on with different styles. So basically Zope 2 will be the framework for Plone only, because the community which is/was using Zope 2 for standalone individual projects has decreased to nearly none. So it might be a good idea to look for something completely different? I don't think that Plone will be able to do everything we want it to. Or do you think we can stick with Zope 2 but change the way of building applications to ZPT/TAL? So we have to get rid of all DTML and what about an alternative to the ZSQL Methods? How long Zope 2.13 is going to be supported and sees security fixes will depend on the community. The Plone community will use it for its 4.1 and 4.2 releases, as a result of our security policy that should result in us supporting Zope 2.13 for the next two years. Beyond that nobody knows what will happen. I do agree. Now i am completely shocked. We are building web applications for the last 6 years in Zope 2.x. All those applications are using the following techniques: [snip] What you are describing is exactly what I meant by old legacy Zope2 applications. You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point. OK, i have subscribed to the mailing list today, so unfortunately i haven't found this sort of information anywhere else. I don't want to blame you or anyone else for that, but it's not nice to hear that right now :-( It might has been too confusing in the past, with Zope 3 being such a mistake and of course i haven't really checked whether to change something or not... Hanno Toby ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2011 11:30, schrieb Martin Aspeli: On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu mailto:ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com mailto:optilude%2bli...@gmail.com wrote: I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. I think it might be useful to spell out the reasons behind this (here, or better yet, somewhere more permanent like zope.org http://zope.org). I can imagine people reading this and wondering why it's a good idea, especially those who have an investment in the existing technologies. Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end. This is a pretty sweeping statement that I think could cause a lot of nervousness. It might be the right thing in many ways, but we need to at least provide a bit more context. If you're a business that's invested dozens of person-years into a product, the prospect of rewriting could seem fairly daunting. At least we, as the Zope 2 community, need to set out the case for change and some kind of idea of timing and transition path, even if that means in some cases getting to a long term maintenance release and in other cases evolving away from certain technologies whilst being confident to keep using others. I agree with Martin, that a sane upgrade path should be provided at least. If people still use things like DTML, the ZMI, etc., then it would be highly frustrating for them to simply drop these. You can split the components from the base and provide them as optional where possible. This seems to be possible with most of the components that Hanno listed as depreciated/to be removed soon. And most importantly: provide sane upgrade paths for depreciated components. If the ancient session management from Zope2 is to be dropped, tell people what they should use instead, and how to migrate their old_but_still_in_use applications/projects. Greetings, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEudWAAoJEFJi5/9JEEn+jXcP/RyNZw1JFfPqG/nzacqAbx4F WdoZGyARkGVV1BTEtE6/cvkJCnHNuBgEaeAtGJY7h5HdqT781uKNdhJurncA8ii3 7RXm0CVJ1AZXdycDT0DoOMyYWBx345cglk5S+5bbfIdMWVvPNyDgQhIjFRT20jA7 cMi8e4mStgd2upwS487L+FubmkWyOw8d8bUbL+SFvykNOEXr6OqwTHLTBWh4yVi3 //zmV6T/wtmcpIyiqdx4VkdvmmttJbM2ro0FcIvO46XHD87XrYSiyEZM3XiYsjiF 8hNqhHtkiA/mLRXw6jIDhMvzvIsgKsWdHMmR2OOGVPY5nnWuvmBimaSj+u01TJIS K1MLMNnheTqH7alr7Mn0PmIGfbX4ED9DwzrR2yen6iHmWqgHShDC+OAFrRzFBK51 fPnLlAVQrQSDLPhhm+Ytv55o/hzmzARUUnta4d+Ac2k0y/DLXuz+8svSdfLuKVyv 0W5onVnLuXH5z5X3HM5ubywUdyfOaVgCIYdV+vVh9tQCeLZsDN6rVl+4H5WCQuNk J17+m4B59zAxAhIxa0ZwnLHVwO+GgP+pIHhQtSZGF1WY43wBFPDxKtt8xxBCjPvk LyMPgevwTn4rhETwkCsZFqMvVGBa/AmKX3suQhNBNFr+8qOy/H/q4tOQGpUyBmNE nVJtAfGh/G+ecROUKMAW =eItl -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 5 July 2011 11:22, Jonas Meurer jo...@freesources.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2011 12:04, schrieb Hanno Schlichting: On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places. I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions. I agree with Jonas that any idea of giving a package named Zope2 a version number that is not 2.x is only going to lead to more confusion. For Zope2 we're used the x in 2.x.y being the major version now anyway, the next release should be 2.14. Lets stick with our convention until we have something that we really do want to promote to users outside the existing development community, I expect that will be a few years away yet. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
Hi, On 5 July 2011 11:26, Tobias Helfrich helfr...@know-it.net wrote: Hi Hanno On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@know-it.net wrote: OK, so you do think that we might use Zope 2.12 for a quite long time without thinking about anymore updates? Will there be any security updates for Zope 2.12 in the future? You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports). Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release. OK, thx for the info. So we will be able to use Zope 2.13 with the techniques mentioned before? That will give us another two years to think about going on with different styles. So basically Zope 2 will be the framework for Plone only, because the community which is/was using Zope 2 for standalone individual projects has decreased to nearly none. I think it would be very sad if that happened, especially since there evidently demand from other projects. What I think is clear is that to evolve Zope 2, we need to shed some baggage and make some deeper changes to allow us to achieve some of our goals (e.g. WSGI, simplified stack, simpler and more easily controllable security, less magical traversal, more comprehensible publisher). Plone is obviously a big consumer of Zope 2 and I would expect Plone to have a major influence on Zope 2's evolution. But ERP5 is another big consumer, and we shouldn't ignore that. So it might be a good idea to look for something completely different? I don't think that Plone will be able to do everything we want it to. Or do you think we can stick with Zope 2 but change the way of building applications to ZPT/TAL? So we have to get rid of all DTML and what about an alternative to the ZSQL Methods? I think keeping DTML as an optional installation should be quite feasible. It's just possibly not something that the core Zope 2 team want to maintain anymore in the standard distribution. ZSQL Methods may be a similar story, in fact, especially as they rely on DTML. However, I'd encourage you to look at SQLAlchemy, which is way nicer to work with. OK, i have subscribed to the mailing list today, so unfortunately i haven't found this sort of information anywhere else. I don't want to blame you or anyone else for that, but it's not nice to hear that right now :-( I think there is some characteristic bluntness in Hanno's emails, but please realise that none of this is going to happen over night, and existing codebases are not going to magically disappear. Sometimes we have to be a bit more radical to understand the art of the possible and build a future platform that will support future needs. That doesn't mean there can't be both migration paths and long-term stable versions. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl j...@dataflake.org wrote: On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu wrote: I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. I actually think it's a brilliant idea to skip 3.0 and call it 4.0. Ok, seems 4.0 is the more popular choice. We'll use that than and make Tres proud (http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project - though zopefour.org has been taken over by a link farm). Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: zopefour as a domain isn't very helpful. It would add yet another top-level name to the existing list (Zope 2, Zope 3). In the best of all possible worlds the package now known as Zope2 would simply be Zope, and its website is at www.zope.org. Zope is making the jump from version 2.x to 4.0. +1 Logically Zope 2.12 would have been a major release due to eggification and dropping Python 2.4. Only makes sense to make label the next major version as such rather than pretending with 2.x that only minor changes are being made. As I've been able to do little or no development this year thanks to Leonardo for raising this and Hanno for his explanation. I do think a public roadmap, with opportunities for people wanting to get involved would be a good idea. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 2:44 PM, Jens Vagelpohl j...@dataflake.org wrote: zopefour as a domain isn't very helpful. It would add yet another top-level name to the existing list (Zope 2, Zope 3). That was an April fools joke I was referring to. I didn't mean to suggest to actually use that in any way ;-) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting ha...@hannosch.eu wrote: Ok, seems 4.0 is the more popular choice. I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5! :-P -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
Martijn Pieters wrote: On Tue, Jul 5, 2011 at 14:41, Hanno Schlichtingha...@hannosch.eu wrote: Ok, seems 4.0 is the more popular choice. I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5! How about ZopeNG? Waiting-for-some-beating, Andreas attachment: lists.vcf___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
On 7/5/11 3:22 AM, zope-dev-requ...@zope.org wrote: Hanno writes: Someone might try, but I think it's not a wise decision to spent any resources that way. I am trying. I am trying to create a Zope 2 like TTW development environment on top of BlueBream. I have a small email list of people who see the world this way. While many core ZTK developers do not like TTW development, there are many of us zope users who do like it. May a thousand open-source flowers bloom. I am making progress. I have ice.control and ZAM running. I have the ZMI running on Zope 3.something.But I am finding it very hard work.I learned quite a bit from this discussion, thank you. All I have to do is subclass the OFS with something that also inherits from acquisition. Cool. And then integrate all the ZMI code into ZAM. Then get the rest of the content types working. I am stuck on figuring out which page template in ZAM to edit. And I am stuck on figuring out how to fire up the ZMI in Bluebream. I will figure it all out.Or I will hire some of the Bluebream guys in eastern Europe to help me figure it out. In any case I now have a project that needs it, so I am motivated. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and TouchTexting http://textfaster.com Expect a paradigm shift. http://MyHDL.org ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] direction
Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com wrote: I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with native interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal: I think what's going to stay is AccessControl, OFS (a bit lighter), ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of Zope Toolkit libraries like components, events, browser pages and so on. That's the kind of scope that should be possible to port to Python 3 and actually modernize enough to be understandable.(...) Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base? If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players. [...] Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] zope-tests - FAILED: 9, OK: 79
This is the summary for test reports received on the zope-tests list between 2011-07-04 00:00:00 UTC and 2011-07-05 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.4.6 64bit linux Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 [1]Zope Buildbot / zope2.13_win-py2.6 slave-win [2]Zope Buildbot / zope2.13_win-py2.7 slave-win Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 [3]Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win [4]Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 [5]Zope Buildbot / zopetoolkit_win-py2.5 slave-win [6]Zope Buildbot / zopetoolkit_win-py2.6 slave-win Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [7]winbot / zc.ngi_py_265_32 [8]winbot / zope.location_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 [9]winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED Zope Buildbot / zope2.13_win-py2.6 slave-win https://mail.zope.org/pipermail/zope-tests/2011-July/045086.html [2]FAILED Zope Buildbot / zope2.13_win-py2.7 slave-win https://mail.zope.org/pipermail/zope-tests/2011-July/045091.html [3]FAILED Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win
