On Thu, Aug 6, 2009 at 12:16 PM, Martijn Faassen<faassen@startifact.com> wrote:
Hey,
Jim Fulton wrote:
I think the KGS should define 3 categories of packages:
- ZTK packages
These are packages we maintain and expect people to build things on.
- Test packages
These are packages that build on the ZTK. These are used to test the ZTK packages, but aren't part of the ZTK.
Could you give an example ofa 'test package'? I'm having trouble thinking of what these might be.
Perhaps Grok (or keas ), or some higher-level framework or application built with the framework. The idea is to catch cases where we've changed the APIs in a backward incompatible way.
- dependencies of ZTK packages or test packages.
Note that the ZTK should probably avoid non-third-party dependencies that are not part of the ZTK. There are some fuzzy cases, like ZODB and ZConfig.
What would 'dependencies of ZTK packages or test packages' be?
Packages that they depend on. Was that a trick question? :)
Aren't those third party packages?
Yes.
I propose that any test infrastructure we come up with needs to handle these 3 cases. In any cases, the test infrastructure needs to fix version for all of the categories of packages and there needs to be a formal process (uh, like tests passing :) for updating the configuration.
Could you say a bit more about what's motivating this proposal?
There's been way too much breakage lately. We have a number of applications here at ZC that can't be upgraded without a huge amount of effort to figure out what combination of packages actually work together. There have also been backward incompatible changes. We'll deal with those, but aren't going to spend time on that until there's a solid foundation. We need a known tested configuration of packages, with their dependencies, that are knows to work -- or at least pass their tests. The purpose of my proposal was to try to move this forward. Jim -- Jim Fulton