While wondering about the ITraverser interface being defined by zope.location, we noticed that the zope.location.pickling.PathPersistent class (which is this package's only user of the interface) is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code as well as make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. What are your opinions on this, does anyone object? -- Thomas
I asked about this before; let me do so again before assuming silence to mean consent: There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code. As PathPersistent is the only user of the ITraverser interface within zope.location, removing it would also make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. Does anyone object to these changes? -- Thomas
Hello, * 2009-09-16 15:34, Thomas Lotze wrote:
There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that.
[snip]
Does anyone object to these changes?
+1, I fully agree with the change. Fabio
Thomas Lotze wrote:
I asked about this before; let me do so again before assuming silence to mean consent:
There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that.
The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code. As PathPersistent is the only user of the ITraverser interface within zope.location, removing it would also make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally.
Does anyone object to these changes?
Sounds like you did the research. I'm +1 on removing it. Regards, Martijn
Martijn Faassen wrote:
Sounds like you did the research.
I've considered all packages mentioned in the current ztk.cfg that come from the zope.* namespace. The BBB stuff from zope.location.pickling is neither used by any of them, nor do compat-tests involving the pinned versions of those packages and the modified zope.location fail. Come to think about it, I'm not sure whether and how far I should investigate beyond the ztk for removals like this; are there zope.* packages in the repository that should no longer be cared about at all?
I'm +1 on removing it.
Done. -- Thomas
Thomas Lotze wrote:
I've considered all packages mentioned in the current ztk.cfg that come from the zope.* namespace. [...]
Come to think about it, I'm not sure whether and how far I should investigate beyond the ztk for removals like this; are there zope.* packages in the repository that should no longer be cared about at all?
I'd like to take this up again: during the last few days I've stumbled on a number of things I'd like to clean up, such as inter-package dependencies or small changes to some API. Everytime I want to go ahead and try some change, or ask this list about opinions along with a best possible description of what it would imply for other Zope packages, I keep finding that it is still not well defined what's the minimal or the optimal set of packages that need to be taken into consideration before committing to the trunk or even releasing a new version of a package. There's also nothing about this on to be found in the ZTK docs unless I've overlooked something obvious. There are a number of sets of packages that are or might conceivably be of interest: - obviously what ztk.cfg lists as included packages - probably what ztk.cfg lists as packages under review - possibly what other packages are pinned by ztk.cfg as dependencies - probably not what's called zope.* in subversion While it is clear that the packages included in the ZTK need to be OK at all times, I'm pretty sure that they alone aren't sufficient. As an additional observation, not all the packages listed as dependencies in ztk.cfg are passing their tests currently: zope.kgs and zope.app.keyreference don't. I'd be very much interested in a clear guideline on which packages need to pass their tests after a change for a developer to feel safe about committing it to the trunk. Stephan: We've talked about this and some related things when you visited us at our office in Halle. Have you made your notes from that meeting available yet? Apologies if I just haven't noticed that you did. -- Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Lotze wrote:
Thomas Lotze wrote:
I've considered all packages mentioned in the current ztk.cfg that come from the zope.* namespace. [...]
Come to think about it, I'm not sure whether and how far I should investigate beyond the ztk for removals like this; are there zope.* packages in the repository that should no longer be cared about at all?
I'd like to take this up again: during the last few days I've stumbled on a number of things I'd like to clean up, such as inter-package dependencies or small changes to some API. Everytime I want to go ahead and try some change, or ask this list about opinions along with a best possible description of what it would imply for other Zope packages, I keep finding that it is still not well defined what's the minimal or the optimal set of packages that need to be taken into consideration before committing to the trunk or even releasing a new version of a package. There's also nothing about this on to be found in the ZTK docs unless I've overlooked something obvious.
There are a number of sets of packages that are or might conceivably be of interest:
- obviously what ztk.cfg lists as included packages
- probably what ztk.cfg lists as packages under review
- possibly what other packages are pinned by ztk.cfg as dependencies
- probably not what's called zope.* in subversion
While it is clear that the packages included in the ZTK need to be OK at all times, I'm pretty sure that they alone aren't sufficient.
As an additional observation, not all the packages listed as dependencies in ztk.cfg are passing their tests currently: zope.kgs and zope.app.keyreference don't.
I'd be very much interested in a clear guideline on which packages need to pass their tests after a change for a developer to feel safe about committing it to the trunk.
Stephan: We've talked about this and some related things when you visited us at our office in Halle. Have you made your notes from that meeting available yet? Apologies if I just haven't noticed that you did.
My take on resolving this issue: - - Having the package's *own* tests pass is the only blocker to checking in to SVN: otherwise we get into a "gridlock" situation. - - If trunk tests for another ZTK package begin failing becuase of trunk changes you make, that would indicate that the *other* package is borked (it shouldn't depend on your trunk). - - If there is an outomated "compattest" buildbot which turns red due to your changes, then you probably need to be available to help fix the dependent package (or maybe update the one you have changed). - - Once you are ready to *release* an update, run the ZTK tests with your released version, just to check for breakage. - - Before checking in an updated versions.cfg to the ZTK trunk, incorporating your new relase, all the ZTK tests *should* pass. If they don't, then you should be in the middle of fixing them, or else don't check in. - - Before tagging a release of the ZTK's versions.cfg, all ZTK tests for the included versions *must* pass. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKu5sJ+gerLs4ltQ4RAtgrAJ4yJiTvoTZ4nOYMXNL3qK4rMskFfACghhOJ AK5cCW5Hn7sZ25Kv99gkA1g= =mkGj -----END PGP SIGNATURE-----
participants (5)
-
Fabio Tranchitella -
Martijn Faassen -
Thomas Lotze -
Thomas Lotze -
Tres Seaver