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.
    • Need to verify twice???
  • May require dedicated machine(s).