[Zope-dev] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Mon Dec 15 12:00:00 2008 UTC to Tue Dec 16 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 15 20:35:43 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010661.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Mon Dec 15 20:37:14 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010662.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Mon Dec 15 20:29:43 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010657.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 15 20:31:13 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010658.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 15 20:32:43 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010659.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 15 20:34:13 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010660.html ___ 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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Christian Zagrodnick wrote: [snip] Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html Weird. At first glance I do not understand the context of that decision. There was a decision to avoid deprecation made by it doesn't seem to be motivated in the discussion: - zope.app.component.interfaces then can import ISite from the new place to avoid deprectation. You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking? I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Christian Zagrodnick wrote: [snip] Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html Weird. At first glance I do not understand the context of that decision. There was a decision to avoid deprecation made by it doesn't seem to be motivated in the discussion: - zope.app.component.interfaces then can import ISite from the new place to avoid deprectation. You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking? I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background. One issue is that adding deprecation messages for importing symbols from the old makes all downstream code add ugly BBB warts in order to suppress them when run against multiple versions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJSBNN+gerLs4ltQ4RAgQUAJsHvpghzkycXNYlOOYC82lCTlUAXQCfT9B0 zIWGClCUqiD/irMMaxwwJzw= =kskl -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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] One issue is that adding deprecation messages for importing symbols from the old makes all downstream code add ugly BBB warts in order to suppress them when run against multiple versions. Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me! This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore. If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code. This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output. Regards Roger Ineichen ___ 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 )
