- Zope-Dev - Zope lists

zope-tests - FAILED: 1, OK: 45
by Zope tests summarizer 25 Nov '11

25 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-23 00:00:00 UTC and 2011-11-24 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.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [1] ZTK 1.1dev / Python2.7.2 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_win32 winbot / ZODB_dev py_270_win64 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 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 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 ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/053119.html

3 2

Re: [Zope-dev] Supporting interworking with repository branches on github
by Tres Seaver 24 Nov '11

24 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/22/2011 05:19 PM, Laurence Rowe wrote: > On 22 November 2011 21:46, Tres Seaver <tseaver(a)palladion.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 11/22/2011 12:13 PM, Laurence Rowe wrote: >>> As you are already aware, at the SF Zope sprint we used Git and >>> github for our work. The work contained in >>> https://github.com/zopefoundation is by people who have already >>> signed the Zope Foundation contributor agreement. >>> >>> While the Zope Foundation deliberates on version control, I think >>> it's likely that development will continue using Git and Github. >>> We want to do this in a way that maintains flexibility for code >>> committed to Git to also be committed to svn.zope.org, so it would >>> be helpful to get a list of Name, Email, username for svn.zope.org >>> committers to facilitate the creation of an author mapping file. >>> (Presumably this information is in LDAP or similar.) >>> >>> We would of course be happy to hand administration rights of the >>> github organization to the Zope Foundation if it was felt to be >>> helpful in ensuring that contributions to that repository counted >>> under the committer agreement. >> >> >> Please don't try to jump the gun on the process here: you should >> be thinking of the existing Github branches as merely "scratchpads" >> for the sprint work, which should be merged into the canonical >> repository when they are ready. It is not appropriate for a small >> subset of the community to preempt this kind of choid: "ask >> forgiveness rather than permission" is *not* going to fly here, and >> trying to push harder only irritates folks you might otherwise >> persuade. > > I think some indication of a timetable for that process is necessary. I said earlier that this kind of decision would be best addressed at the annual meeting of the foundation in Q1 2012. I also indicated that I didn't think github vs. the SVN status quo was the only possible choice. > The view of many of those at the sprint was that it would be less > work to simply fork and develop a custom publisher for Plone. I imagine that the effort is substantially bigger than you think. I also don't think that the damage to community goodwill would be negligible here. > I think there is value to keeping that work under the auspices of the > Zope Foundation as it may be helpful for other projects currently on > Zope 2. But realistically, unless the Zope Foundation is interested > in supporting those developers looking to work on a new project by > enabling them to use a modern version control system then my view is > unlikely to prevail. First, this is not a "new project": the existing github repos contain what are really a handful of commits across two projects (Zope and Products.ZCatalog; the ZConfig and Products.PythonScripts repos don't have any commits). The deltas are very small compared to the installed base, and could be trivially landed back in SVN today, either on the respective trunks or on branches. Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. What *is* being "blocked" here is a push by a relatively small group of committers[1] to impose a unilateral change to a long-established development culture, without prior consultation, and backed by a not-very-thinly-veiled threat of a fork. [1] I count you, rossp, mikko, and garbas as having non-merged branches. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7NCEkACgkQ+gerLs4ltQ73uACfY1d309afRKU0K1d4/BTV4Uf7 RS0AnjE6xFQro9pkbH3Yqk7mnOd8FbFk =t4Eo -----END PGP SIGNATURE-----

4 3

zope-tests - OK: 46
by Zope tests summarizer 24 Nov '11

24 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-22 00:00:00 UTC and 2011-11-23 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.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 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_win32 winbot / ZODB_dev py_270_win64 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 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 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 0

Supporting interworking with repository branches on github
by Laurence Rowe 23 Nov '11

23 Nov '11

As you are already aware, at the SF Zope sprint we used Git and github for our work. The work contained in https://github.com/zopefoundation is by people who have already signed the Zope Foundation contributor agreement. While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. We want to do this in a way that maintains flexibility for code committed to Git to also be committed to svn.zope.org, so it would be helpful to get a list of Name, Email, username for svn.zope.org committers to facilitate the creation of an author mapping file. (Presumably this information is in LDAP or similar.) We would of course be happy to hand administration rights of the github organization to the Zope Foundation if it was felt to be helpful in ensuring that contributions to that repository counted under the committer agreement. Laurence

4 4

Enabling External Methods in skin folders
by lists＠nidelven-it.no 23 Nov '11

23 Nov '11

Hi, I have a bunch of External Methods I'd like to make available in a skin form, and which reload in the same way a page template would if it was modified and the server was in debug mode. What's the recommended product for enabling this now? -Morten

2 2

zope-tests - FAILED: 1, OK: 45
by Zope tests summarizer 23 Nov '11

23 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-21 00:00:00 UTC and 2011-11-22 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.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 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_win32 winbot / ZODB_dev py_270_win64 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 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 [1] winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-November/053050.html

3 2

Zope 4 roadmap
by Laurence Rowe 22 Nov '11

22 Nov '11

Here's my current understanding of the Zope 4 roadmap. Zope 4 ------ Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS - Remove XML zexp export (davisagli). - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. - Decorators for AccessControl (chaoflow). Future releases (Zope 5, 6, etc.) --------------------------------- There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. - Unicode IDs in OFS - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item - New ZMI - Move authentication out to WSGI middleware. Long term --------- - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need - Move to Python 3. Laurence

6 8

Revert removal of ++skin++ in Zope4?
by Christian Theune 22 Nov '11

22 Nov '11

Hi, I'd like to revert the removal of the ++skin++ traverser in Zope 4. As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature. From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework. I couldn't find an argument anywhere why ++skin++ should be gone. Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations

7 17

zope-tests - OK: 46
by Zope tests summarizer 22 Nov '11

22 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-20 00:00:00 UTC and 2011-11-21 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.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 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_win32 winbot / ZODB_dev py_270_win64 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 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 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 0

Version number policy if default values change
by Patrick Gerken 21 Nov '11

21 Nov '11

Hi, GenericSetup wasn't very good in handling non ascii chars on exporting. I changed the behavior so that it will only dump strings to files/zodb/tgzs and modified the provided exporters to default encode text as utf-8. Since this breaks packages, I'd increase the minor number from 1.6 to 1.7. To get a plone system to work with these changes, I needed to update Products.DCWorkflow, Products.PluggableAuthService and Products.PluginRegistry. Since in all these packages I only changed the default encoding from None to utf-8 I wonder if this requires a higher minor number or not. I'd say no, as anything that was just stored as ascii, would be properly decoded as utf-8 too. So before I change the numbers and ask for new release, I'd like to ask if anybody objects. Best regards, Patrick

2 1