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