# Presentation: 329885

## D0 ReleasesCDF-Presentation2/12/01

- General Strategy
- Weekly
- Production
- Very similar to CDF’s procedures I believe, so I’ll say very little about this.
- Weekly Release (General)
- Versions
- Web Release Request System
- Building a release
- Developer’s perspective
- Release Manager’s perspective

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- General Strategy
- Weekly Releases, start Monday afternoon
- More or less matches most developers’ timeframe
- too fast more often than too slow
- Coordinated by SubSystem Coordinators
- Daily “bug fix” builds
- “Freeze” on Friday (but...)
- Available on disk for ~3 weeks
- “stable” base for development
- available for remote distribution
- archived after that
- Production releases
- Targeted at some specific executable or set of executables, sometimes **all** major executables.
- Coordinated by Production Release Manager
- different people depending on targeted executable(s)
- Extensive verification.
- Once “frozen” can go onto the farms and to remote production facilities.
- Available on disk and for distribution for a “long” time, until superceded.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Weekly Releases
- Versions are “rtag”d in cvs
- Release requested via the Web based Release Request system
- Package
- Version
- Release notes (not very useful usually)
- Special requirements (simultaneous releases etc)
- Approved by subsystem coordinator
- coordinate interface changes within and between subsystems.
- coordinate development
- Daily builds with “bug fixes”, address **only** problems reported by the error mailings from previous builds that week
- request via Web Release Request system
- direct to release managers
- coordinators are notified so can abort request.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Versions are “rtag”d in cvs
- Allows use of cvs in the way that it’s meant to be used
- Concurrent development at widely scattered sites
- Can be used to “transport” code between machines
- Encourages committing changes frequently, changes don’t need to be fully tested until the release has been requested
- Can ask other people to test the code before release
- addpkg <pkg> <tag>
- rtag vs tag
- PRO
- rtag goes into history file      cvs history -Tan <pkg>
- can determine what tags exist without checking out the package.
- CON
- only tags the head (main trunk or branch)
- tagging must precede full testing
- unlikely to run out of numbers, so not a real problem.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Release Request System*http://www-d0.fnal.gov/software/cmgt/releaserequest/*
- Could be fully automated
- We’ve chosen to put people into the loop at several places
- Weekly (by 15:00 Monday afternoon)
- Developer rtag’s packages
- Developer requests release
- SubSystem Coordinator approves release
- Release Manager makes the final choice
- pretty much all of those approved
- has to beat on coordinators to approve or explain why not.
- Daily Bug Fixes (by 15:00 each day) **supposed** to be only fixes to problems that were found in that weeks build
- Developer rtag’s packages
- Developer requests release (bug fix)
- Release Manager makes the final choice
- Most bug fixes **should** be because of interactions between packages, but, in fact, some developers let us do their testing for them, especially on platforms other than their main development platform.
- Full history and status of requests, by package, coordinator and release is available online (Oracle db)

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Building a Release
- Developer’s perspective
- newrel -t <base release> <working directory>
- addpkg -h <pkg>
- addpkg <pkg>  (version in <base release>)
- addpkg <pkg> <version>
- . . .
- gmake
- gmake test
- other tests
- edit
- loop
- cvs commit
- rtag
- request release (“normal” or “bug fix”)

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Building a Release
- SubSystem Coordinator’s perspective
- Talk to developers
- Monday
- Check for new release requests (Monday)
- Make sure the requests match what the group is trying to do.
- Approve requests as appropriate
- Daily
- Monitor SubSystem’s error logs
- Push developers to supply corrections
- Find someone to supply corrections
- Monitor “bug fix” requests
- Friday
- SubSystem Coordinators’ Meeting
- Participate in status discussion
- Announce planned interface changes
- Coordinate global changes with other coordinators.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Building a Release
- Release Manager’s perspective
- Could be fully automated
- Monday
- checkout skeleton
- checkout release stream independent tools
- checkout release stream dependent files
- Allows separate release streamsUnix (IRIX and Linux)NTOnline (OSF1)
- declare to ups
- Chose the packages/versions to be released
- Mail contains package/versions
- edit “inventory” file
- simply a list of all packages/versions in that release
- “exppkgs.sh”, exports package/version if doesn’t already exist, declares to ups
- forcepkglinks.sh, creates sym links to package/version
- BldTable.sh, builds D0RunII.table
- buildrel.sh, “gmake all; gmake test” with some special manipulations that we have to do.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Building a Release
- Release Manager’s perspective
- Daily (Tuesday, Wednesday, Thursday)
- Bug developers/coordinators to get fixes
- Help developers to interpret error logs
- Point out why their package(s) failed to build
- Chose the packages/versions to be released
- Mail contains package/versions
- edit “inventory” file
- simply a list of all packages/versions in that release
- “exppkgs.sh”, exports package/version if doesn’t already exist, declares to ups
- forcepkglinks.sh, creates sym links to package/version
- BldTable.sh, builds D0RunII.table
- buildrel.sh, “gmake all; gmake test” with some special manipulations that we have to do.

- D0 Releases-Alan Jonckheere

- 2/12/01

## D0 ReleasesCDF-Presentation2/12/01

- Building a Release
- Release Manager’s perspective
- Friday
- SubSystem Coordinators meeting
- summarize release status
- decide if extra builds are needed1 or 2 over the weekendall next week (rarely happens)
- decide if release is too broken to save(rarely happens)
- Freeze release (Friday or Monday morning)
- d0freezerel.sh, freeze rcp database, freeze other data files, make tar files, install tar files on upd distribution node, declare to ups/upd.

- D0 Releases-Alan Jonckheere

- 2/12/01