Last (and only) tag was v0r3 on Jan 17.
13, out of 36 packages have been updated to the latest head, 1.26.
There has never been a build that passed all the unit tests. (But only the last three current versions are available).
We need to address the issues identified by Heather:
- ROOT is not verified, and there are serious questions about it
- the RootHistCnv in the new Gaudi is badly flawed
- there is a problem in the termination of G4Generator:
WARNING - Attempt to delete the physical volume store while geometry closed !
WARNING - Attempt to delete the logical volume store while geometry closed !
WARNING - Attempt to delete the solid store while geometry closed !- the windows version of HTL is not the same as that used by linux.
We cannot run the validation tests due to ROOT problems.
ROOT is preventing us from installing vc7.
On the release system status page, there are 3 columns of versions.
GlastRelease package list
package released in v0r3 current (head) latest tags
On the left is the latest GlastRelease tag - a release, and by definition past history.
In the middle are the versions specified by the HEAD of GlastRelease - this is to be the next release.
The column on the right is a predictor of the next release - it lists the latest tags, not just the ones slated for the next release. Each of these is built nightly, so we know their state. As the future column becomes error free, we can be more sure that future releases will be smooth.
Currently, Alex manually updates the head of GlastRelease, responding to emails to the core mailing list. In the future, the "future" versions would have a "Promote Me" button next to it (suitably protected if needed), which would promote the latest tag of the package into the head of GlastRelease. To be pushed by the package owners. The next build would verify success (the build could be triggered on tag of GlastRelease if we want). In this idea, the web form would check out GlastRelease, modify the appropriate version in the reqs file and commit it. Once the GlastRelease head builds ok, we can call it a release. We would run the system tests on it as a final arbiter (perhaps tagging it first).
The package HEAD issue: do we care if it builds? Should there be any record? OTOH, what if a developer wanted to see how the build system would treat it if it were tagged. Is there a mechanism to test it locally, rather than having to wait overnight?
What about other queries of the cvs history?
T. Burnett Last update: Wednesday, 04. August 2004 15:42:08 -0700