D0/Run 1/Level 2/Configuration Management
The Good, The Bad and The Ugly
Presented by: Dan Claes for Alan M. Jonckheere
at the D0 - Run 1 - Level 2 - Postmortem
22 May 1996
The Good
D0 it again
- Well Controlled versions.
- Specific versions accessible "for all time".
- Contents of versions well understood.
- Build on FNALD0/Run in LEVEL 2
- All time consuming building and verification done remotely,
no possibility of accidentally putting untested code into use.
- Simple COPY to on-line to release it.
- Debug worked (with care) without rebuild.
- Release Notes allowed one to figure out what happened between
releases.
- Relatively easy to build and backfit versions.
- Physics Group reps "passing" on releases.
- Relatively knowledgeable interface with people using the data
produced (interested parties are always best!)
The Bad
Do not do it again
- I can't think of anything that was really bad.
After all we had several years to shake it down.
The Ugly
Try not to do it again
- Too much code in the "bug fix" CMS archive, not
tied tightly to "main" archives.
- Potential for code to drift far from development versions.
- Potential to lose developments.
This happened several times. Most recently between V6 and V7.
Code that goes into a Pass Release, but not into the main archive
won't get into the next major release.
- Hard to determine what the real differences were between releases.
- Release Notes made it possible.
- Must religiously make meaningful entries.
- Hard to determine what versions are really necessary to maintain
for posterity.
Recommendations
- Maintain code versioning and retrofit capabilities.
- This is one of the main requirements of our configuration
management design effort now ongoing, so it will
happen.
- Tie code more closely to main archive. i.e.) use CVS "branches"
rather than a separate archive to handle fixes etc.
- Stays closer to main development path.
- But this makes it even harder to determine what changed
between versions.
- Make release notes mandatory for main development path? How
to enforce?
- Most likely will require much more frequent major releases,
but should make these easier to do.
- Link results of verification to release notes
- Short write-up in release notes?
- WEB links to full results? Summaries?
- Maintain "Off-line" build and verification capability.
- Care needs to be taken to determine that any "off-line"
build is gives "equivalent" results to the on-line version.
- May require dedicated machine(s).