Version 1.9 Build 1488

News	FAQ
Search	Home

AIPS++ decision log

AIPS++ Project Management
National Radio Astronomy Observatory
P.O. Box O, Socorro, NM, 87801, USA

Text last updated: 2001 July 19
HTML version available at:
http://aips2.nrao.edu/docs/project/decisionlog/decisionlog.html

Purpose

This document records the date, background and results of major decisions taken during project development. It is edited and maintained by the project management.

Date: 2001-06-11: Open formal decision log

Background

While decisions have been recorded in the project documentation up to now, including project status reports, weekly meeting minutes and e-mail exploders, a central reference is important for easy access by project members. This was agreed in the Software Engineering practices described in Note 237.

Result

Created file doc/project/decsionlog.latex. Will make visible on the AIPS++ web page and maintain as a central repository of major AIPS++ project decisions.

Date: 2001-06-15: Drop support for IRIX 32-bit

Background

The parallelization group have been using a 64-bit IRIX build with the SGI native C++ compiler for all production runs and regular devlopment. A 32-bit version was maintained however, as Rational did not support 64-bit development in the IRIX version of Purify. The latest version of Purify IRIX now provides this.

Result

Dropped support for IRIX 32-bit, and terminated all AOC builds of this type.

Date: 2001-07-02: Check-in policies and build stability

Background

Build stability is vital in the current operational phase, both for developers and scientific end-users. Strategies for achieving this are defined in Note 237 (Software engineering practices in AIPS++), and in prior e-mail discussions (TC aips2-workers #2240).

Result

Refresh and clarify the current check-in policy (revised aips2-workers #2240).

Maintaining the stability of daily is a high priority for everyone in the project. Breaking daily affects the work of a large number of people.
Maintaining the stability of weekly is essential. Breaking weekly is disastrous for the work of a large number of people. Our goal should be that every weekly can be marked as stable.
Checkins of changes to existing code should be made with the above two goals in mind.
Changes to code that is used by others must be well-tested on the project compiler before checkin, including running the associated assay() tests. Checkin of purely developmental code is less crucial but still good habits should be followed.
All checkins except simple ones, and bug fixes should be done early in the week. Early means with two more of your inhales to get it right before the final weekly.
If you have a substantial change that will require more than a week to test, this should be explictly scheduled in consultation with the project management so that it can be coordinated across the consortium.
All development sites should be running a daily using the project compiler.