Distribution
This page is concerned with the professional side of MeqTrees, making sure the the more mercurial cats have a reliable, up-to-date and well-tested MeqTrees kernel to work with. Our front man here is Chris Williams ( [[christopher.williams@oerc.ox.ac.uk|mailto:christopher.williams@oerc.ox.ac.uk]] ) in Oxford, under the benign local guidance of Stef Salvini ( [[stef.salvini@oerc.ox.ac.uk|mailto:stef.salvini@oerc.ox.ac.uk]] ).
We will attempt to get out a new release on openSuse 11.1 and ubuntu 9.04 by August 1st. Packages will be made available for pre-release testing asap. Any serious problems found during this stage will lead to the abandonment of this release, due to the unavailability of staff. This release will not be released on any other platform.
The Qt4 port release has been scheduled for the 15th September. This is a very optimistic time schedule and is likely to be changed
For the moment, this is just a list of the things we propose to do in the near future:
- openSUSE 11.1 binary distribution - as a yum repository for both 64bit and 32bit
- requires extra packaging functionality to handle subpackages and variants (e.g. qwt runtime and development versions built against qt3 and qt4)
- requires new build system (done?)
- requires gcc 4.3 port
- Mac distribution
- Initially a MacPorts distribution (self build)
- Later a dmg (binary) distribution
- Mac chroot issues currently being investigated by Oxford university Computing Support
- Ubuntu 9.04
- Fedora (rpm/yum based distro)
- Possibility of a stand alone binary distro (statically linked)?
For a package that is distributed for various operating systems, and undergoes frequent upgrades, a good automatic testing system is an absolute must. Unfortunately, it is not all that easy, both techically as sociologically. We should look at the way other projects are dealing with this.
The present TRUT system is a first stab at automatic testing. It simply tries to compile a list of python modules in a particular sub-directory. This already catches a lot of errors, most of them caused by pure sloppyness. It is not clear yet how we should proceed to unit testing and regression testing. Watch this space.
Since MeqTrees will be used for large data processing jobs (both simulation and calibration), it must be parallellized. While developing the core classes, OMS has always built in the hooks to allow this, and the default implementation already supports multiple threads for use on multi-core machines. In June 2008, a first parellellized version was produced by OMS and Stef Salvini. This is now in the process of being vigorously tested by Stef and the end2end sky simulations group in Oxford. Depending on this, we may be able to offer a parallellized version in 2010 to deserving users. The latter are people who are demonstrably proficient in the use of MeqTrees, and have local technical expertise to deal with the special problems of parallel processing. Watch this space.