November 2011 - Zope-Dev

Zope 4 release management
by Laurence Rowe 12 Jun '12

12 Jun '12

Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission ------- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. Development Process ------------------- We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. Laurence

17 32

Re: [Zope-dev] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
by Ross Patterson 11 Apr '12

11 Apr '12

I've done some more work on this and I've gotten the component registrations fully working now with one exception that I'm having real trouble with. I'd like some help with that, more below. I'm also a bit more clear on what might be appropriate to bring back into zope.interface and I'd like feedback on that. Currently interfaces are pickled as globals. Given their centrality in any ZCA application, I think they should be pickled using a function: def __reduce__(self): return (find_interface, (modulename, globalname)) where find_interface, if ZODB.broken.find_global can be imported, in turn calls: ZODB.broken.find_global(modulename, globalname, Broken=IBroken, type=InterfaceClass) since find_global already has nicely abstracted graceful missing global handling. If this were added to zope.interface, and changed ZODB objects with marker interfaces or persistent registries where all the code for the interfaces is still available will then be updated with pickles that will gracefully handle missing interfaces in the future. Thus you could use zodbupdate to make sure that the interfaces in your ZODB will fail gracefully in the future. Do you agree/disagree that this belongs in zope.interface? What this will not address are existing interfaces-as-globals pickles where the original interface is now missing. That's where the other patches in experimental.broken come in, they intercept the two contexts where we can infer that a missing global should be an interface: instance provides declarations and persistent component registries. By hooking into the unpickling of those objects, we can replace broken classes with broken interfaces as appropriate for those structures. With these patches installed it should be possible to use applications with missing interfaces and to use zodbupdate to make sure that even *already missing* interfaces will fail gracefully both now and in the future. I think these patches don't belong in zope.interface/component and if they work I would likely move them to five.localsitemanager along with a ZCML file that is not loaded by default. Does that sound right? Then one thing I haven't been able to get working is making it possible to commit a changed persistent registry when it includes a component registration for a non-persistent component whose class/type is missing. This works just fine for a *persistent* component whose class/type is missing but fails for a non-persistent component. The error is: AttributeError: 'Bar' object has no attribute '__Broken_newargs__' More specifically, '__Broken_newargs__' is set by the Broken.__new__ method and I've confirmed that this isn't being called by instrumenting __new__, __init__, and __setstate__. Only __setstate__ is called when unpickling the non-persistent broken component not __new__ as should be. Below is the full traceback. I've also left the package repo in the broken state if you want to examine it, the egg checkout is also a buildout: https://github.com/rpatterson/experimental.broken/commit/a4b648dc78e53c7303… Any help with this last issue would be appreciated. Ross Ross Patterson <me(a)rpatterson.net> writes: > Please take a look at experimental.broken: > > https://github.com/rpatterson/experimental.broken > http://pypi.python.org/pypi/experimental.broken > > The handling of broken objects by the ZODB can make an application with > add-ons that use zope.interface far too fragile. If marker interfaces > from an add-on are used on objects in the ZODB, removing that add-on can > make any zope.interface operation on that object fail. Even worse, if > an add-on registers any components in a registry in the ZODB, that > entire registry will become unusable for any ZCA operations which pretty > much breaks everything, including admin interfaces. > > Since the interfaces and the ZCA are often core parts of an application > using the ZODB, it may be appropriate to add special handling for broken > objects to those services. The experimental.broken patches are my > attempt to prototype such special handling. > > For objects in the ZODB which directly provide a marker interface, > these patches allow that object to behave as without the application > of the marker interface if the interface is no longer available. If > the interface is made available again, the full behavior of that > interface is restored. Similarly, if a component whose class, > provided interface, or required interfaces are missing, these patches > allow the registry to perform lookups it would have been able to do > without the broken component registration. If the component > class, provided interface, and required interfaces are restored, > then the component registration is fully restored. > > If an object or registry in the ZODB is committed to the ZODB with > broken interfaces or components, the commit will succeed and it is still > possible to fully restore previous behavior if the missing classes and > interfaces are restored. Unfortunately, because interfaces are pickled > as globals, there's no good way to have the same pickle written on > commit for the interface as was in the original pickle, but it should > behave exactly the same. > > The intention of this package is to see if the implementation of broken > object handling is correct and robust enough to merge into > zope.interface and zope.component themselves. Is this the right > approach? If not why and what would be better? How might this approach > be improved? > > Ross > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1

7 10

Re: [Zope-dev] [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
by Malthe Borch 08 Apr '12

08 Apr '12

On 7 November 2011 09:17, Ross Patterson <me(a)rpatterson.net> wrote: > The intention of this package is to see if the implementation of broken > object handling is correct and robust enough to merge into > zope.interface and zope.component themselves. Is this the right > approach? If not why and what would be better? How might this approach > be improved? (removed plone-dev from cc). Isn't it symptom treatment though? If you've got an add-on which adds marker interfaces to "general objects", shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces. I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a "hard remove" of an add-on without a prior "soft remove". \malthe

3 2

zope.sqlalchemy+py3 test failures.
by Chris McDonough 06 Dec '11

06 Dec '11

In case anyone is interested, I've made a stab at porting zope.sqlalchemy to Python 3 at http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/ . Several tests still fail. I could use some help fixing them. To run the test suite: - Create a Python 3.2 virtualenv. - Install nose into the virtualenv. - Check out the "chrism-py3" transaction branch from svn://svn.zope.org/repos/main/transaction/branches/chrism-py3 - Install the "chrism-py3" transaction checkout into the virtualenv, e.g. $env32/bin/python setup.py develop. - Install this package into the virtualenv eg. run $env32/bin/python setup develop. - Run $env32/bin/python setup.py nosetests. Currently 2 tests fail: [chrism@thinko zope.sqlalchemy]$ env32/bin/python setup.py test running test running egg_info writing requirements to src/zope.sqlalchemy.egg-info/requires.txt writing src/zope.sqlalchemy.egg-info/PKG-INFO writing namespace_packages to src/zope.sqlalchemy.egg-info/namespace_packages.txt writing top-level names to src/zope.sqlalchemy.egg-info/top_level.txt writing dependency_links to src/zope.sqlalchemy.egg-info/dependency_links.txt writing manifest file 'src/zope.sqlalchemy.egg-info/SOURCES.txt' running build_ext testTwoEngines (zope.sqlalchemy.tests.MultipleEngineTests) ... ok testRetry (zope.sqlalchemy.tests.RetryTests) ... ERROR testRetryThread (zope.sqlalchemy.tests.RetryTests) ... ERROR testAbortAfterCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testAbortBeforeCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testBulkDelete (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testBulkUpdate (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testCommitWithSavepoint (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testMarkUnknownSession (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testRelations (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testRollbackAttributes (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testSavepoint (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testSimplePopulation (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testThread (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testTransactionJoining (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testTwoPhase (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok ====================================================================== ERROR: testRetry (zope.sqlalchemy.tests.RetryTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1633, in _execute_context context) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/default.py", line 327, in do_execute cursor.execute(statement, parameters) sqlite3.OperationalError: no such table: test_users The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/tests.py", line 513, in setUp self.tm1.commit() File "/home/chrism/projects/transaction/transaction/_manager.py", line 89, in commit return self.get().commit() File "/home/chrism/projects/transaction/transaction/_transaction.py", line 342, in commit reraise(t, v, tb) File "/home/chrism/projects/transaction/transaction/compat.py", line 60, in reraise raise value File "/home/chrism/projects/transaction/transaction/_transaction.py", line 333, in commit self._commitResources() File "/home/chrism/projects/transaction/transaction/_transaction.py", line 473, in _commitResources reraise(t, v, tb) File "/home/chrism/projects/transaction/transaction/compat.py", line 60, in reraise raise value File "/home/chrism/projects/transaction/transaction/_transaction.py", line 445, in _commitResources rm.tpc_begin(self) File "/home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/datamanager.py", line 87, in tpc_begin self.session.flush() File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py", line 1493, in flush self._flush(objects) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py", line 1562, in _flush flush_context.execute() File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py", line 327, in execute rec.execute(self) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py", line 471, in execute uow File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/mapper.py", line 2147, in _save_obj execute(statement, multiparams) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1399, in execute params) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1532, in _execute_clauseelement compiled_sql, distilled_params File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1640, in _execute_context context) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1777, in _handle_dbapi_exception from e sqlalchemy.exc.OperationalError: (OperationalError) no such table: test_users 'INSERT INTO test_users (id, firstname, lastname) VALUES (?, ?, ?)' (1, 'udo', 'juergens') ====================================================================== ERROR: testRetryThread (zope.sqlalchemy.tests.RetryTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1633, in _execute_context context) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/default.py", line 327, in do_execute cursor.execute(statement, parameters) sqlite3.OperationalError: no such table: test_users The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/tests.py", line 513, in setUp self.tm1.commit() File "/home/chrism/projects/transaction/transaction/_manager.py", line 89, in commit return self.get().commit() File "/home/chrism/projects/transaction/transaction/_transaction.py", line 342, in commit reraise(t, v, tb) File "/home/chrism/projects/transaction/transaction/compat.py", line 60, in reraise raise value File "/home/chrism/projects/transaction/transaction/_transaction.py", line 333, in commit self._commitResources() File "/home/chrism/projects/transaction/transaction/_transaction.py", line 473, in _commitResources reraise(t, v, tb) File "/home/chrism/projects/transaction/transaction/compat.py", line 60, in reraise raise value File "/home/chrism/projects/transaction/transaction/_transaction.py", line 445, in _commitResources rm.tpc_begin(self) File "/home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/datamanager.py", line 87, in tpc_begin self.session.flush() File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py", line 1493, in flush self._flush(objects) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py", line 1562, in _flush flush_context.execute() File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py", line 327, in execute rec.execute(self) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py", line 471, in execute uow File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/mapper.py", line 2147, in _save_obj execute(statement, multiparams) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1399, in execute params) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1532, in _execute_clauseelement compiled_sql, distilled_params File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1640, in _execute_context context) File "/home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py", line 1777, in _handle_dbapi_exception from e sqlalchemy.exc.OperationalError: (OperationalError) no such table: test_users 'INSERT INTO test_users (id, firstname, lastname) VALUES (?, ?, ?)' (1, 'udo', 'juergens') ---------------------------------------------------------------------- Ran 17 tests in 0.152s FAILED (errors=2) This appears to be some sort of Py3+SQLite thing, beacuse if I run the tests using Postgres isntead of SQLALchemy (after "env32/bin/easy_install py-postgresql", and then running the tests using 'TEST_DSN="postgresql+pypostgresql://localhost:5432/testing" env32/bin/python setup.py nosetests' against Postgres 8.4.8 after a "createdb testing"), I get different failures: ====================================================================== FAIL: testRetryThread (zope.sqlalchemy.tests.RetryTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/tests.py", line 564, in testRetryThread self.assertTrue(retryable, "Error should be retryable") AssertionError: None is not true : Error should be retryable -------------------- >> begin captured logging << -------------------- txn.140333906949888: DEBUG: new transaction txn.140333906949888: DEBUG: commit <zope.sqlalchemy.datamanager.SessionDataManager object at 0x2dd6ed0> txn.140333906949888: DEBUG: commit txn.140333906949888: DEBUG: new transaction txn.140333906949888: DEBUG: new transaction txn.140333906949888: DEBUG: commit <zope.sqlalchemy.datamanager.SessionDataManager object at 0x2dda9d0> txn.140333906949888: DEBUG: commit txn.140333906949888: DEBUG: new transaction txn.140333906949888: DEBUG: abort txn.140333906949888: DEBUG: abort --------------------- >> end captured logging << --------------------- ---------------------------------------------------------------------- Ran 18 tests in 5.099s FAILED (failures=1)

5 15

zope-tests - FAILED: 5, OK: 42
by Zope tests summarizer 30 Nov '11

30 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-28 00:00:00 UTC and 2011-11-29 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 [1] winbot / zope.keyreference_py_265_32 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 [2] winbot / ztk_dev py_265_win32 [3] winbot / ztk_dev py_265_win64 [4] winbot / ztk_dev py_270_win32 [5] winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED winbot / zope.keyreference_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/053374.html [2] FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-November/053375.html [3] FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-November/053376.html [4] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-November/053377.html [5] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2011-November/053378.html

3 3

Re: [Zope-dev] Fwd: [Checkins] SVN: zope.app.folder/trunk/ Conform to repository policy
by Tres Seaver 30 Nov '11

30 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/29/2011 11:48 AM, Gediminas Paulauskas wrote: > ---------- Forwarded message ---------- From: Zvezdan Petkovic > <zvezdan(a)zope.com> Date: 2011/2/2 Subject: Re: [Checkins] SVN: > zope.app.folder/trunk/ Conform to repository policy To: Gediminas > Paulauskas <menesis(a)pov.lt> > > > I noticed your checkins similar to this: > > On Dec 28, 2010, at 2:12 PM, Gediminas Paulauskas wrote: > >> Log message for revision 119203: Conform to repository policy ... >> Modified: zope.app.folder/trunk/setup.py >> =================================================================== >> --- zope.app.folder/trunk/setup.py 2010-12-28 17:10:33 UTC (rev >> 119202) +++ zope.app.folder/trunk/setup.py 2010-12-28 19:12:47 >> UTC (rev 119203) @@ -1,6 +1,6 @@ >> ############################################################################## >> >> # >> -# Copyright (c) 2006 Zope Corporation and Contributors. +# >> Copyright (c) 2006 Zope Foundation and Contributors. > > > This is right. The copyright holder is the Foundation now. > > >> # All Rights Reserved. # # This software is subject to the >> provisions of the Zope Public License, @@ -21,13 +21,13 @@ def >> read(*rnames): return open(os.path.join(os.path.dirname(__file__), >> *rnames)).read() >> >> -version = '3.5.2 dev' +version = '3.5.2dev' >> >> setup(name='zope.app.folder', version=version, - author='Zope >> Corporation and Contributors', + author='Zope Foundation and >> Contributors', > > > This is NOT right. This code was written in Zope Corporation and that > does not change with the transfer of the copyright. The author is not > equal to the copyright holder. > > Please read this thread here and Christian Theune admission that he > was wrong about checking for author in his conformance scripts. > > https://mail.zope.org/pipermail/zope-dev/2010-May/040514.html > > So, can we please stop changing authors. For the package in question here ('zope.app.folder'), ZC is in *now* way an author: 'svn log' says that the majority of people who ever checked into the package was not ZC employees at any point. That change was from one piece of boilerplate (used when ZC was the copyright holder) to another piece (after the transfer). For such a collectively-originated work, the ZF is a much better placeholder than ZC: it exists to represent the collective interests of the Zope development community. 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/ iEYEARECAAYFAk7VSTEACgkQ+gerLs4ltQ7WWACgh+S/BgX5YRxsajcvkqRrI/sq Wr0AoKFOb4DrSNZHx7Z9iCZcHvT760M4 =faMk -----END PGP SIGNATURE-----

2 1

Re: [Zope-dev] SVN: zope.catalog/trunk/ Fix ZPL version in file headers
by Tres Seaver 29 Nov '11

29 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/29/2011 11:47 AM, Gediminas Paulauskas wrote: > 2011/11/29 Tres Seaver <tseaver(a)palladion.com>: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 11/29/2011 10:39 AM, Gediminas Paulauskas wrote: >> >>> =================================================================== >>> >>> - --- zope.catalog/trunk/setup.py 2011-11-27 22:25:03 UTC (rev 123517) >>> +++ zope.catalog/trunk/setup.py 2011-11-29 15:39:53 UTC (rev >>> 123518) @@ -26,7 +26,7 @@ >>> >>> setup(name = 'zope.catalog', version = '3.8.2dev', - >>> author='Zope Foundation and Contributors', + author='Zope >>> Corporation and Contributors', >>> author_email='zope-dev-CWUwpEBWKX0(a)public.gmane.org', >>> description='Cataloging and Indexing Framework for the Zope >>> Toolkit', long_description=( >> >> >> Hmm, that doesn't look right: ZC transferred all ownership of code >> to the foundation. > > I've got mails from people in Zope Corporation where they complained > that author is changed without reason. Copyright is transferred to > Foundation, but author is still the Corporation. Since there was no > release with changed author, I reverted this change. "Zope Corp." didn't write the code for either zope.catalog or zope.app.catalog (from which it was drawn): all that code is written by individuals, many of whom were not employees of ZC at the time. If there *is* a single (primary) author, then listing that *person* as author is fine, but otherwise the Foundation works better than ZC as a "collective author". 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/ iEYEARECAAYFAk7VFC4ACgkQ+gerLs4ltQ6jOwCfaXPIkmDhLA1LRRk6/QQ651zl 5oIAoMiPk7suvs9iM1K8Lk9zePOuHITU =4Osf -----END PGP SIGNATURE-----

2 1

Re: [Zope-dev] SVN: zope.catalog/trunk/ Fix ZPL version in file headers
by Tres Seaver 29 Nov '11

29 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/29/2011 10:39 AM, Gediminas Paulauskas wrote: > =================================================================== > --- zope.catalog/trunk/setup.py 2011-11-27 22:25:03 UTC (rev 123517) > +++ zope.catalog/trunk/setup.py 2011-11-29 15:39:53 UTC (rev 123518) > @@ -26,7 +26,7 @@ > > setup(name = 'zope.catalog', version = '3.8.2dev', - author='Zope > Foundation and Contributors', + author='Zope Corporation and > Contributors', author_email='zope-dev(a)zope.org', > description='Cataloging and Indexing Framework for the Zope Toolkit', > long_description=( Hmm, that doesn't look right: ZC transferred all ownership of code to the foundation. 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/ iEYEARECAAYFAk7VAAwACgkQ+gerLs4ltQ4BDgCgzfOYy018Zmzh8lztNyrKcBvn Yb8Ani8tjtOOX83aJTZS8HIEvY1ekRxK =o2pe -----END PGP SIGNATURE-----

1 0

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

29 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-27 00:00:00 UTC and 2011-11-28 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

Mailing lists moved
by Jens Vagelpohl 28 Nov '11

28 Nov '11

Hi all, I moved all mailing lists to a newer server this weekend. If anyone is noticing any problems please talk to me off-list. jens

1 0