Calgary Developers Meeting Notes

03 Jun 2006

---

see also

• CalgaryDevelopersMeetingMeetingNotes (Friday)
• CalgaryDevelopersMeetingMeetingNotesSunday
• CalgaryDevelopersMeetingMeetingNotesMonday

---

Testing

Assay

• We need an update to the AssayManifesto.
• What's the purpose of each data file?

What's falling down is that Gary had done that initial collection of scripts into a new assay, but that assay has stagnated,

new features from calibrator that george has written, that are not even in our regressions, that must be added

1. add features into the
2. easier so people don't run full-blown tests when they don't have to

There is a Lite version of the assay.... but only for Imager

JoeMcMullin: Isn't now the time to re-factor the tests in the assay, while we're moving things over from Glish to the new framework?

Packaging and DataRepository

Because you need a new subset of data -- DarrellSchiebel reports there is a layering now to the DataRepository (base or core) and base is all that's needed for the simple tests:

• Base -- (what you need to run)
• Core -- (can only run basic, minimal assay)
• Complete

RaymondRusk: Why have any CasaConsortium stuff if it isn't asked for? OK...

• Consortium

Currently we also have:

• Utility
• ProtoPipe

The Data RPMs are really out of date. We had machine fail about two years ago and we've never

What's needed to get that done, all the IERS information?

Don't we have scripts to build the RPMs? They are on Tarzan (which is going away).

Let's talk about DataRepository tomorrow, because there are a lot of issues.

Regressions

A Web page that's published peridically. SummerStudentProject.

Migration: Release New Testing

In principle, we could have the test script before having the migration. It involves reading through all the Glish examples to find things that can be used for a test...

Do the test migration by September. You want the calibration test scripts and imager test scripts.

Raymond: I never really got finished doing Measures.

What suite of tools are we going to support?

• Measure
• Simulator
• Plotter
• Viewer
• ComponentModel (ComponentList)
• Fitting
• Functionals
• AutoFlag
• Polarimetry

C++ calls Plotter in histogram images.

Freezing AIPS++

They want to jump on the bandwagon -- a few tools that are used (eg) by the JIVE folks.

• WimBrouw
• KumarGolap

Is Freezing Re-Factoring?

Basically, the idea here is that we could pull out the glish, freeze the interface, stop development in glish. But new development in CASA would be able to benefit the old glish. Consortium members could continue development in glish.

• Basically, the group is nervous about this idea. Consensus is that Freezing means Freezing: keep the whole AIPS++ repository where it is, no re-factoring, it's not further maintained.

ACS

Do we need an ACS port (that is, explicit ACS bindings rather than going through Python)?

CcmTools already supports MICO, a CORBA binding.

Our current plan is that we give ALMA a binary RPM that gives all the functionality... Script that's checked in under AcsTools, the new ProtoPipe should run at that point.

Python Integration issue

Issue is Python -- our shared libs must be able to be loaded by their Python interpreter.

Java Integration Issue

The only question for Lindsay is, how often are they going to want to call our stuff from Java?

Current plan is to wrap the Java clients (stubs) in Python components and call our stuff via Python.

Integration Troika

We need a protocol by which these ACS/ALMA/CASA integration issues are addressed.

For example, we discover a memory leak bug in the version of Python that ALMA is using which prevents Pipeline from running. We determine a fix to the Python binary: how do we push that back onto ALMA?

Consortium Members

The MOU ran out 1 June.

The ATNF, the Dutch Consortium members -- give them a branch.

TimCornwell was upset about the idea of a branch. But we should adopt a development model such that the developers are not second-class citizens.

Branches:

• Active Development Branch(es)
• Stable (Main)

Every 2-3 months, we perform a full regression test, and then tag Development branch as Stable.

Development on a Branch, Patches

1. Development is done on a branch
2. Patch is submitted
3. acceptance protocol
   1. We apply the patch on test envrionments
   2. regression testing
   3. acceptance

How does this affect anyone's day-to-day development?

• The developers check into the CVS DEVLOPMENT branch.
• In addition, they submit a patch to WesYoung for testing and acceptance into the main branch. Or rejection.

Developers each have their own sandboxes.

The place this breaks down is where the regression tests don't cover the issue. eg the ParallacticAngleBug. But that's a seperate issue.

MeqTreeSimulator - TonyWillis

CasaMigration - WesYoung

SupportedPlatforms

DefectHandling

PackagingAndDistribution

SourceCodeControl

-- BoydWaters - 03 Jun 2006