[Zope-dev] Testing guideline

[Tres Seaver]

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