Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 22 Dec 2005, at 17:09, Martin Aspeli wrote: Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Complete overkill, sorry. We're dealing with one project here, and for starters we need a simple document, and then go from there. Matter of fact a simple Wiki would be good, probably right underneath www.zope.org/Products/CMF. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Either, you can create a project on plone.org/products and use the features there, or you can set up a standard Plone 2.1 site and install PloneSoftwareCenter (note that you currently need the 2.1-integration branch; we're working on getting a real release out) and its dependencies (ArchAddOn, ExternalStorage optional). Here, you can get the same roadmap features for any project. Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? The new way (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 21 Dec 2005, at 11:14, Florent Guillaume wrote: Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6- compatible then? The new way (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Thanks a lot Florent, I assume Martin can go off and do his magic with that description. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Well now I'm *completely* confused. grin - Rocky Alexander Limi wrote: On Wed, 21 Dec 2005 00:32:02 +0100, yuppie [EMAIL PROTECTED] wrote: AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. Just a terminology correction here, the next version of Plone is 2.5, not 2.2 - we changed our version policy a while back: http://plone.org/products/plone/roadmap/114 http://plone.org/roadmap (Not that important for this discussion, but just a heads-up so you non-Plone people don't get confused about 2.2 vs. 2.5 when we talk about it later. :) -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 21 Dec 2005, at 12:06, Raphael Ritz wrote: Starting to look into this myself I just wasted a couple of minutes because of my outdated setup (I had a plain Zope-2.8.4-final release) Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Yes, this will need some cleanup before the first beta. Instead of upgrading Five, I thought I better get Zope-2.9.0b1 which wanted me to upgrade my Python to 2.4.2. I only have a 2.4.1 around with I took and now everything seems OK. You can just download and put Five 1.2b into your INSTANCE_HOME, it will be loaded in preference to the stuff in the SOFTWARE_HOME jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Rocky Burt wrote: Raphael Ritz wrote: Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Zope = 2.8.5 Five = 1.2 So I got a Zope-2.8.5-final only to realize later that this ships with Five-1.0.2 :-( Your best bet is to install Zope 2.8.5-final and then install Five 1.2b (in your instance home Products dir). Not sure what other troubles Zope 2.9b1 would bring to the table here. I'm currently working on having CPS work with CMF 1.6 branch and Zope 2.9 branch. I've had a few fixes to make already, today most things should work. A few more may come when I test deeper. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364r1=40360r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 13:10, Martin Aspeli wrote: Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364r1=40360r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? I don't know what the checkin was supposed to do apart from a cleanup, that's why I am asking Yvo. That CMFDynamicViewFTI doohickey (no idea what that is, really, but Plone needs it for some reason) tries to import typeClasses from CMFCore.TypesTool and add information about itself to it. See fti.py module. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi Jens! Jens Vagelpohl wrote: The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?rev=40364r1=40360r2=40364 I'm in the specific situation where I have an existing Plohn 2.1 site and I want to use PAS. The latest PAS depends in a current GenericSetup, so I am trying to move the Plone site onto the current CMF 1.6 branch. Due to the change above this is not possible. Question: If we claim CMF 1.5 compatibility, do you mind reverting this checkin? The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi Rob! Hi Jens! Rob Miller wrote: Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. Besides the import/export handlers Rob mentions below this affects all the TypesTool code that used 'typeClasses' (grep for it in 1.5) and the add forms for type infos. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 21:56, yuppie wrote: yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi! Jens Vagelpohl wrote: On 20 Dec 2005, at 21:56, yuppie wrote: I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. It might be that the problem was hidden before I removed the typeClasses list. But the typeClasses list wasn't really used on the 1.6 branch. Only in manage_addTypeInformation, where the new way to register type info classes was ignored. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. I'm fine with any decision as long as someone else does the necessary work. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? We can obviously fix this, so long as we maintain API compatability. A lot of products use CMFDynamicViewFTI, but only through the interfaces defined there and in CMFPlone/interfaces/browserdefault.py. *If* this is indeed a better solution, we'd need to know *how* to change CMFDynamicViewFTI to use the new machinery. That code is fairly small and simple, and someone who knows how an FTI works should hopefully not have much problem understanding how it works. If you can outline how to fix it, I'm sure we could get one applied and into a release timed to the switch to CMF 1.6. Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 update
Florent Guillaume wrote: Rob Miller wrote: - need to readd the PortalGenerator portal creation mechanism for CMFDefault.Portal, for backwards compatibility this is done. the unit test is still failing, however. for some reason, in CMFDefault.tests.test_Portal.CMFSiteTests, globals()[__warningregistry__] doesn't seem to exist. i'm not sure how this is supposed to work, exactly... The is put into place by the warnings module as soon as the first warning is emitted. See warnings.py. ah, thank you! yes, in the older test_Portal, it is implicitly assumed that the warning registry has been created _before_ the test in question is reached. since all of the other unit tests are now using GenericSetup to create the site, no warnings had yet been generated. fixed and committed the test, all CMFDefault tests are now passing. -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
Chris Withers wrote: Alec Mitchell wrote: to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. I'm sorry, I really couldn't resist this... neither can I ... And that differs from other Plone releases how exactly? ;-) not at all, but that's what many people (including yourself?) didn't like so far. So maybe it's time for a change? ;-) Raphael Chris ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
On Fri, 18 Nov 2005 00:37:47 -0800, Chris Withers [EMAIL PROTECTED] wrote: Alec Mitchell wrote: to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. I'm sorry, I really couldn't resist this... And that differs from other Plone releases how exactly? ;-) And what, exactly, have you done to help Plone have less bugs? I know you get income from Plone consulting, how about making your workday better *and* pay back for the stuff you get for free? You are seriously starting to piss me off, Chris - as the only person in the Zope world so far. An achievement in itself, but not one you should be particularly proud of. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
Alexander Limi wrote: And that differs from other Plone releases how exactly? ;-) And what, exactly, have you done to help Plone have less bugs? *sigh* there's not a lot I can do, the problems with Plone are cultural. There seems to be a pervasive culture of monkey patching and bludegeoning code to meet functionality requirements while not worrying about software architecture, refactoring, scalability or performance except in passing fads. Yeah, sure it works out of the box like it should, and it has all the checkbox features, and it even looks pretty if that's the look you like, but try and do anything that doesn't ship out of the box and _doesn't_ involve the aforementioned code blugeoning and you end up with a solution that will only work for your specific project because of the Plone-wide assumptions you have to break to get it done. Either that or not give a damn about performance or maintainability and just make it work. Sure, it'll work for a few releases without change if you're lucky, but it'll likely be dog slow and pig ugly if you look behind the scenes. I'm sorry, that kind of coding just doesn't interest me. But, inspite of that, you will see the odd change I've made to try and help, and I try and provide simple tools like zdb, Stepper, MailingLogger, SimpleUserFolder and MailTemplates that people are free to use without any obnoxious GPHell licensing and without having to worry about some semi-formed ip assignment that may or may not stand up in any given court of law around the world. I know you get income from Plone consulting, how about making your workday better *and* pay back for the stuff you get for free? Because I can't. The win's we've had on the one big Plone-related (and there's not _much_ of Plone actually left now, sorry to tell you) project I work on have been by stripping out all the complexity so that code meets the _project_ requirements and doesn't worry about interacting with any of the myriad of Plone half-interfaces and semi finished rubbish that gets shipped as part of every release. You are seriously starting to piss me off, Chris Don't worry, the quality of code that ships in the Plone bundle has already done much to take me way beyond pissed off. I find it a tragedy that a project with such a large following can't manage to get anyone capable of actually standing back and taking a good hard look at the quality of some of your key components and sorting it out rather than tacking on the next whizz-bang feature in a similarly half-arsed manner. - as the only person in the Zope world so far. An achievement in itself, but not one you should be particularly proud of. Honestly, I'm sorry you feel that way but at least I make the distinction about what it is I'm pissed off about. The people in the Plone community are great, and I get on with the majority of them very well as far as I know, but sadly, that alone doesn't make them write good software. I am pissed off with the _software_ not the _people_ and if I thought there was a sane way I could make things better, I would. But again, honestly, I think the software that currently makes up Plone above the CMF, and even that could do with a good kick, is beyond help and would only really be improved by a ground-up rewrite. And finally, if you're pissed off with me, that's fine, I don't really give a monkeys how you feel towards me personally. Write some good software, then I might ;-) cheers, Chris PS: Sorry for the rant, I was hoping to avoid this heading to a list but the one liner I posted earlier was as good as I could make it, I even put the smiley in ;-) For Alex to reply like this has now got the response it deserved. Really, I was excited to try Plone 2.1 with all the hype about the quality being so much better and improved performance, but having just had to give up on another project involving Plone 2.1 and LinguaPlone because it was way too slow, particularly on Windows, and trying to fix any of the problems I found felt like playing some sick and twisted version of whack-a-mole, not to mention the fact that Plone still ships with failing unit tests that cause other product's unit tests to fail means that while I have loads of respect for the project in managing to grow such a large community, and particularly for the people who have the patience to take part, I have zero respect for the software that underpins it... -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
On Fri, 18 Nov 2005 05:49:46 -0800, Chris Withers [EMAIL PROTECTED] wrote: snip rant / Rant accepted, and understood. Still, you could try to help out instead of *just* bitching. I am an expert bitcher myself, but at least I do something about it. Thread closed? Feel free to follow up with me in private email if there's anything we can do to facilitate you helping out. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guys, I'll ask that this end here on the zope-cmf list (well, Alex is entitled to one public rebuttal, I guess). We need to focus the list's discussion and attention on ways to improve the architecture, rather than engaging in a your code is crap flamewar. FWIW, the Goldegg work is largely aimed at making it possible to resolve the product vs. framework dichotomy in Plone, by making it possible to extract / reuse / reimplement features developed to meet a given need as Z3 components. I am *very* excited to be working with both Plone and CMF developers to make that happen. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfd74+gerLs4ltQ4RAs5hAKCIQ0rkwjlI1EGW2ewmqlREuIsO8ACfR62U xlpNSVCtCT52zb1pQ8KM3ls= =3KhU -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6
Florent Guillaume wrote: I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. As a bystander, I have a suspicion that this discussion might be helped via an IRC appointment? --Paul ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF-1.6 branch created (was Re: backporting GenericSetup to CMF-1.5)
Jens Vagelpohl wrote: On 14 Nov 2005, at 22:28, Rob Miller wrote: okay, i've created a CMF-1.6 branch that has branched everything from CMF-1.5 with the exception of CMFSetup and GenericSetup, which are svn:externals from the CMF trunk. note that i've haven't actually started any backporting yet, and as such this branch is completely non-functional. i hope to actually start work on it tomorrow evening (california time). By the way, since this discussion is happening on the zope-dev list right now as well, please don't just jump in and create release branches. The release manager should do that, after reaching a consensus of what it should contain and when to cut it. We should maintain some semblance of order here. ah, okay. sorry 'bout that. -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
