[Zope-dev] zope-tests - FAILED: 10, OK: 31, UNKNOWN: 1
This is the summary for test reports received on the zope-tests list between 2011-09-05 00:00:00 UTC and 2011-09-06 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 [1]UNKNOWN : winbot / ZODB_dev py_270_win32 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit [2]ZTK 1.0dev / Python2.4.6 Linux 64bit [3]ZTK 1.0dev / Python2.5.5 Linux 64bit [4]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-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_win64 [5]winbot / zope.pagetemplate_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 [6]winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 [7]winbot / ztk_dev py_254_win32 [8]winbot / ztk_dev py_265_win32 [9]winbot / ztk_dev py_265_win64 [10] winbot / ztk_dev py_270_win32 [11] winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : winbot / ZODB_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049167.html [2]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049176.html [3]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049178.html [4]FAILED ZTK 1.0dev / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049177.html [5]FAILED winbot / zope.pagetemplate_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-September/049170.html [6]FAILED winbot / ztk_10 py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/049197.html [7]FAILED winbot / ztk_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049190.html [8]FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049191.html [9]FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/049192.html [10] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049193.html [11] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/049194.html ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote: > * Chris McDonough [2011-09-01 04:27]: > > It wouldn't be the end of the world to have the global registry and the > > global API live in zope.registry, but it doesn't help Pyramid for it to > > be in there, and it probably wouldn't help anyone else either. The > > global API (which includes getSiteManager) is really just a convenience > > feature, and splitting that global API across more than one package > > doesn't seem to make sense to me. > > I guess this is the central issue where we have different opinions. > I don't consider those "just convenience", but rather concept-bearing > of their on right. "Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc? > > It might make sense for the entire global API to be in zope.registry, > > but if you take "global API" to mean what it does now that implies > > dependencies on at least: > > > > - zope.event (zope.component.event.dispatch) > > - zope.testing (for addCleanUp of the global registry in > > z.c.globalregistry and other places) > > Yep, those two would be necessary. This is a bit icky for me. I'd rather have something with fewer dependencies, or at least dependencies I actually use. > > It also implies conditional dependencies on zope.security (in > > z.c.hooks.setSite, and other places), which are even now pretty nasty. > > But I don't see where that would come from. As far as I understand it, > hooks.setSite wouldn't be in zope.registry. If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3. Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself. - C ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough [2011-09-01 04:27]: > It wouldn't be the end of the world to have the global registry and the > global API live in zope.registry, but it doesn't help Pyramid for it to > be in there, and it probably wouldn't help anyone else either. The > global API (which includes getSiteManager) is really just a convenience > feature, and splitting that global API across more than one package > doesn't seem to make sense to me. I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right. > It might make sense for the entire global API to be in zope.registry, > but if you take "global API" to mean what it does now that implies > dependencies on at least: > > - zope.event (zope.component.event.dispatch) > - zope.testing (for addCleanUp of the global registry in > z.c.globalregistry and other places) Yep, those two would be necessary. > It also implies conditional dependencies on zope.security (in > z.c.hooks.setSite, and other places), which are even now pretty nasty. But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ 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 )
