 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
The master copy of the aips++ source code will be kept on one machine at Charlottesville (baboon) for redistribution to all other consortium sites. In order to preserve the notion that consortium sites ``own'' their own parts of aips++ , they may be given exclusive rights to check code in and out of these areas. It will be their responsibility to update the master copy in Charlottesville with bug-fixes and enhancements, and thereby make it available to the other consortium sites.
At the June 1991 aips++ meeting it was decided that consortium sites would play a role in redistributing aips++ to their geographical region in order to share the load. ATNF, for example, would cater for the Australian astronomical community. Since distribution will mainly be via anonymous ftp, this scheme would be observed as a gentleman's agreement by aips++ recipients. For example, there would be nothing to stop an Australian site from acquiring aips++ directly from Charlottesville, they will simply be asked to get it from Epping. End users should register with their local consortium site for the purpose of receiving bug-reports, newsletters and the like, and also for statistical and political purposes. The user database should include the hardware configuration and operating system releases so that users with like systems may be put in contact with each other (by agreement). A master list of all aips++ sites should be maintained at Charlottesville.
The anonymous ftp directories for aips++ will contain compressed
tar files of the complete plain text copy of the latest release of
aips++ . Separate tar files would be supplied for each of the
aips++/code subdirectories to allow end-users to fetch only those parts
of aips++ that they were interested in. These would be used to build the
base version of the aips++ system. Sites which are not on the internet
will require distribution of aips++ by tape. In addition to the full
release, there should also be a separate area for patch files for significant
bug-fixes effected since the last full release. These should contain
bug-fixes only and be independent of the latest revision of aips++ which
will probably contain new bugs. AIPSSERV, the 
IPS email server,
could be used to distribute these bug fixes to sites not on the internet. A
list of the email addresses of aips++ recipients should be maintained at each
consortium site, and when a new bug patch is received email should be sent to
all sites automatically.
In order to protect ourselves from end-users who are too tardy in updating their aips++ installation we should declare from the start that we will not support releases of aips++ which are too old. Two years seems like a fair and reasonable time.
The policy adopted in redistributing third-party software is that it be made available with the aips++ release, but that end-users not be required to duplicate what they already have. This can be achieved by having a separate anonymous ftp area containing individual compressed tar files for each package. Recipients can chose what they want, or mget the whole lot.
The subject of distributing binaries was raised in the tools exploder discussions. It would be fairly straightforward to distribute binaries for all architectures and operating system releases for which aips++ can be built at consortium sites. However, it is inevitable that many sites will not be able to take advantage of this because of incompatibilities in the revision of the operating system, compiler, etc.
Consortium sites will maintain their copy of the aips++ source code in CVS repositories. A compressed tar file of the base version of the CVS repository would be kept in an anonymous ftp directory separate from the plain text version. Two schemes for distributing updates to the CVS repository could be adopted. Both are based on distributing complete copies of individual RCS files from within the CVS repositories.
In fact, these two schemes are not mutually exclusive, both could be catered for at the Charlottesville end. For example, it might be reasonable for consortium sites to apply daily updates during the week, and do a full update each weekend to guarantee the integrity of the system on that time scale. Either way, a separate procedure would also have to be delivered by Charlottesville to delete files from the CVS repositories at the receiving sites to account for files which had been removed from the master copy.
The 
tp/aips++ directory hierarchy might resemble the following
+---- README
|
+--- import ----+--- make-3.62.tar.Z
| +--- PGPLOT-4.9.tar.Z
| +--- libg++-1.39.0.tar.Z
| +--- :
|
| +--- install ---+--- README
| | +--- VERSION
| | +--- V3.1.tar.Z
| |
| +--- kernel ----+--- README
| | +--- VERSION
| | +--- V3.1.tar.Z
+---- code -----+
| +-- synthesis --+--- ...
| +---- vlbi -----+--- ...
| +---- dish -----+--- ...
| +---- atnf -----+--- ...
| +---- bima -----+--- ...
| +---- drao -----+--- ...
| +---- nfra -----+--- ...
| +---- nral -----+--- ...
| +---- nrao -----+--- ...
| +---- tifr -----+--- ...
| +--- contrib ---+--- ...
---+---- aips++ ---+
|
+----- sun4 ----+--- README
| +--- VERSION
| +--- OS4.0.3c.tar.Z
| +--- OS4.1.1.tar.Z
|
+----- cvex ----+--- README
| +--- VERSION
| +--- OS10.1.tar.Z
| :
| :
|
+-- bug_fixes --+--- README
| +--- VERSION
| +--- V3.1.5.Z
|
+-- consortium -+--- README
+--- VERSION
+--- CVS3.1.tar.Z
+--- CVS3.2.tar.Z
+--- CVS3.3.tar.Z
+--- :
+--- CVS3.update.tar.Z
Both versions of the update mechanism are represented in the
tp/aips++/consortium subdirectory, where CVS3.update.tar.Z
represents the update referred back to the base release,
CVS3.1.tar.Z. The script which deletes files removed from the CVS
repositories in Charlottesville would be contained within the update itself.
In general, the compressed tar files will probably have to be split into reasonable sized files. The VERSION files will simply contain a version number for comparison with the recipients installed version. The procedure which automatically fetches the update file at consortium sites, or the bug-fix file at end-user sites, will check this version number against their currently installed version and halt if it hasn't been incremented. The base release number will always be of the form ``n.1'', and the bug-fixes which branch from the base release, will consequently have a third version number field, ``n.1.m''. In general there will be one new incremental release per day in the life of a base release, so the second version number field will increase to quite high numbers.
The mechanics of updates to consortium sites will require a cron job which
runs at Charlottesville each evening to produce an update and place it in the
tp/aips++/consortium directory. Some time later at the recipients
end, a cron job will run to fetch the update, apply it, and then make
aips++ . Because of the international nature of the project, the effect of
time zones must be taken into account. The following timetable has been
constructed on the assumption that the update is placed in the anonymous
ftp area in Charlottesville at 1900 local time. Note that each
consortium member may have several sites at which aips++ is under active
development. The time difference quoted is with reference to Charlottesville,
without allowance for daylight saving.
time wait
difference local start time
Site (hr) time time (hr)
ATNF
Epping +15 1100 1900 8
(Culgoora) +15 1100 1900 8
(Parkes) +15 1100 1900 8
BIMA
Illinois -1 1800 1900 1
Maryland 0 1900 2000 1
(Berkley) -3 1600 1900 3
DRAO
Penticton -3 1600 1900 3
NFRA
Westerbork +6 0100 0200 1
Groningen +6 0100 0200 1
Leiden +6 0100 0200 1
NRAL
Jodrell Bank +5 0000 0100 1
NRAO
Charlottesville 0 1900 1900 -
Greenbank 0 1900 2000 1
Socorro -2 1700 1900 2
TIFR
Poona +10.5 0530 1900 13.5
Bombay +10.5 0530 1900 13.5
As shown by the timetable, most of the western hemisphere sites should be able
to collect the aips++ update and begin a make within a few hours of it
being made available in Charlottesville, even allowing for a minimum wait-time
of one hour. In the worst case, NFRA will have only half a night to
remake aips++ , but this should be sufficient. However, assuming that
the update should not begin before 1900 local time, the Australian and
particularly the Indian sites will be somewhat disadvantaged by long wait
times. Also, since TIFR is not on the internet, the update files will have to
be distributed to them by email using AIPSSERV.
The converse of source code distribution is that of receiving feedback from end-users. Electronic mail addresses should be set up to deal with this, and in particular, separate addresses should be provided for bug-fixes, bug-reports, and requests. The first two categories will have a high priority. End-users should mail bug reports to their local consortium member, not necessarily Charlottesville. However, consortium members should forward all email reports to Charlottesville for cataloguing in a central repository. In some cases, consortium members may need to pass on certain bug reports to other consortium members who have responsibility for a particular piece of code.