Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

VDT 1.1.13 post-mortem

After the release of VDT 1.1.13, Carey, Parag, and Alain gathered to talk about how the release process went. What went right? What went wrong? Most importantly, what can we do to make it better? Here are the results of that meeting.

Overall, we are really happy with the lastest VDT. With Parag's involvement in NMI, our builds have been going much smoother. Our increasing automation has been great. We need to automate more processes as we are able to do so, but the improvements have already been seen, such as the RPM installation test script.

We need better interaction with the VDT testers, and probably need to have our own test grid that they can interact with.

Our internal "to do" list was very useful and we should keep up the excellent internal communication.

Our communication with external people has improved, but it can be even better. We have to be on the alert for things that we need to tell other people about.

New Rule: we must always run the full test suite on all platforms before we release. We did this, but then we made "just a little change" and released it with just a partial test. From now on, we always do a full test.

New Rule: We must always let 24 hours elapse from the time we made the last change in the VDT to before we release it. We hate having the "Doh!" feeling in the middle of the night, after realizing that our last change was not perfect.

While our web page documention has improved, we need to be more careful about editing the same files at the same time. Ditto for the Pacman cache. From now on, we will not touch those files directly. Carey will implement a new solution, probably using CVS with an automated script to update the final destination.

We should keep a separate directory hierarchy for each VDT version for the software binaries, to ensure that a change to VDT N does not affect VDT N-1. We should be more cautious to prevent this, but having a distinct copy of software for each VDT version will prevent this problem from happening.

We need to improve our understanding of dependencies in the software.