Alex, Heather, Joanne, Karl, Leon, Richard, Toby (Traudl in absentia)
Topics:
Current strategy
we have been using Gleam as our container package, specifying the exact versions of the constituent packages. The HEAD of Gleam has been the building ground for the next Gleam tag - it lists the tags of the packages going to be used. Toby has been preparing this and finds out through the grapevine (most of the time) what to use.
A package tag is expected to compile, link and run its test program successfully. The HEAD of a package is hoped to do same.
The Release Manager builds the latest Gleam tag and HEAD, plus the latest tag and HEAD of a pre-set list of packages.
What's the problem?
there is not a good way for (at the moment) Toby to know which tags should go into the next Gleam
the (non-Gleam) package builds are a crap shoot. At the moment, these are treated as container packages. For all package versions, there can be wild-carded uses of other packages, making it hard to figure out where to assess blame for failure - frequently package builds fail due to failures in other used packages; for the HEAD, it might also be that they depend on the HEADs of other packages - there is no way to specify this.
Proposed Solutions
Create a TestRelease container package listing the latest "blessed" tags of all packages (a superset of the ones Gleam needs). This set of tags are beat upon so that they build together.
A package tag need not be 'good'. There still seems to be considerable sentiment that a tag build and run; just that the performance of the code may still be on the road to good but not there yet.
The latest tag and HEAD of Gleam are still built in the current manner.
The nightly builds have the TestRelease build in its CMTPATH, and a 'local' build is performed on the packages for the latest tag.
For the HEAD, a mechanism will be created to allow developers to optionally specify that they require the HEAD of some other package to build properly. This may be a standard format file they place in their package containing the list of needed HEADs.
Potential Problems
For the HEAD builds - the developer will forget to reset the "other-HEAD" instructions when they are no longer needed.
how do we maintain the TestRelease list of tags? Can we intercept (via vcmt/glastpack?) cvs rtag to query the developer on whether he wants this tag in TestRelease?
Last Modified: 2002-09-13 09:38:03 -0700