-----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-----