Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
FWIW I patched EE's trunk on svn.zope.org. Thanks. Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul. Then the framework never gets cleaned up. So be it. This is really minor. Not deprecating it is the right thing, and I won't even qualify that with a "IMO" ;-) - C ___ 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] Re: OFS.Application deprecations for Zope 2.10
On 14 Jun 2006, at 00:45, Chris McDonough wrote: On Jun 13, 2006, at 4:13 PM, Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. You're right. This only because I haven't managed to get off 2.8 on any of my projects, so I just never see these warnings. The reason I haven't been able to make it off 2.8 is due mostly to other deprecation/feature addition aggressiveness that has taken place in 2.9 and on the HEAD. Us plain old folks just can't keep up. I really wouldn't at all mind releasing a patched EE if the thing being deprecated was worth deprecating. But IMO this was a bad deprecation, and we should just un-deprecate it. FWIW I patched EE's trunk on svn.zope.org. If we don't remove things at some point, there's no point in doing deprecation warnings. I think the deprecation shouldn't have been done in the first place. This is only about "methods" not about __ac_permissions__ and so on that have warnings in the file. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul. Then the framework never gets cleaned up. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Re: OFS.Application deprecations for Zope 2.10
On Jun 13, 2006, at 4:13 PM, Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. You're right. This only because I haven't managed to get off 2.8 on any of my projects, so I just never see these warnings. The reason I haven't been able to make it off 2.8 is due mostly to other deprecation/feature addition aggressiveness that has taken place in 2.9 and on the HEAD. Us plain old folks just can't keep up. I really wouldn't at all mind releasing a patched EE if the thing being deprecated was worth deprecating. But IMO this was a bad deprecation, and we should just un-deprecate it. If we don't remove things at some point, there's no point in doing deprecation warnings. I think the deprecation shouldn't have been done in the first place. This is only about "methods" not about __ac_permissions__ and so on that have warnings in the file. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul. - C ___ 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] Re: OFS.Application deprecations for Zope 2.10
On 13 Jun 2006, at 21:51, Tres Seaver wrote: Florent Guillaume wrote: Chris Withers wrote: Chris McDonough wrote: view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute. Removing it breaks longstanding and widely-used third-party products, which means that anyone upgrading will have to upgrade the products at the same time. The win in this case is mostly aesthetic, which makes the removal less attractive. Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Re: OFS.Application deprecations for Zope 2.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > Chris Withers wrote: >> Chris McDonough wrote: >>> view, but this wouldn't work for non-URL lookups. So people who use >>> 'methods' now will need to monkeypatch in hideous ways just like the >>> 'methods' stuff does now, in which case why not leave it? >> >> Am I right as reading this as someone else who feels "why are we >> deprecating this just for the sake of it?" ? > > If you need monkey patching I don't see why the framework should help you. > This should be extremely rare occurences with big comments, not use of a > magic 'methods' class attribute. Removing it breaks longstanding and widely-used third-party products, which means that anyone upgrading will have to upgrade the products at the same time. The win in this case is mostly aesthetic, which makes the removal less attractive. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjxdW+gerLs4ltQ4RAgn+AJ9vvrz2MW0n8LPFLUrBYF9HHGATcQCghIkm AW9iLTYZlySmRwH3m6Z6BC4= =Q7Ax -END 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] How do I get involved in volunteering?
On Tue, Jun 13, 2006 at 11:15:12AM -0700, Christopher Lozinski wrote: > Maybe there is a trade show where all the key players show up once a year. A lot of people come to pycon and the europython conference. > I think in the Plone world, at least there are the two key players, and > then the board, so there is some visible structure. In the Zope world > it is not so clear. google for "zope foundation". > So here are my questions. How does one get involved? http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_06_07_join-zope-foundation-now >Who is in > charge? Jim is still the Zope Pope. > Who approves cvs submissions? Nobody / everybody. i.e. there's no formal process, but people often complain about checkins they disagree with. It's generally resolved informally and amicably. -- Paul Winkler http://www.slinkp.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 )
[Zope-dev] How do I get involved in volunteering?
I am interested in volunteering, but I am somewhat lost. And I say that even though I have been developing in Zope for years, and reading this email list avidly for a year. I think that I am going to go and buy and read the Zope 3 book. Beyond that I do not know what to do. The problem is that I have no idea what direction Zope 2 is taking. Although I have poked around on the web, I do not get Zope 3. The Zope 3 class seems a bit expensive, for those of us who are self-unemployed and who want to volunteer on Zope 2. I would love to read an architectural document, if it exists. If not maybe I could write it. It would start off by describing the different target markets and competing products. It would then define the requirements for those target markets, and it would finish by describing the architecture for zope 2 and 3 that meets those target markets. Of course that is the reverse of how it actually happened, but it sure makes a good story. I even think that in the process of creating such a high level view of this industry, I might come up with an additional market or two, and an additional architecture for Zope n to meet the requirements for that market. For example, I know that I like ZClasses and versionning, and they are not part of the plan. Then I could figure out how Zope development figures in with my product plans, and could figure out the best place to apply my energies. Maybe there is a internal group of zope 2 developers who have these conversations and who know which way things are going. Maybe no one knows, and as changes get delivered, they get approved. I am not even sure who is in charge of approving the cvs changes, and who is allowed to contribute to the cvs. Is there a list of the annointed high priests somewhere? Who annoints the approved code? Maybe there is a trade show where all the key players show up once a year. I think in the Plone world, at least there are the two key players, and then the board, so there is some visible structure. In the Zope world it is not so clear. So here are my questions. How does one get involved?Who is in charge? Who approves cvs submissions? What is the target architecture? What are the target markets? Regards Chris ___ 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] Re: OFS.Application deprecations for Zope 2.10
Chris Withers wrote: Chris McDonough wrote: view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Re: OFS.Application deprecations for Zope 2.10
Chris McDonough wrote: view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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 )