CellML Discussion List

Text archives Help


[cellml-discussion] physiome project developer infrastructure


Chronological Thread 
  • From: s.blackett at auckland.ac.nz (Shane Blackett)
  • Subject: [cellml-discussion] physiome project developer infrastructure
  • Date: Tue, 02 Oct 2007 15:47:52 +1300

Hi Andrew,

I agree that many of these items are desirable.

I am very keen to see an integrated solution that covers at least all of
our public physiome project developments. So as you select things
please consider how they may be used by cm, cmgui (and zinc) and OpenCMISS.

I will also point out that we have existing infrastructure for one of
these which is heavily utilised.

I also advocate the goal of trying to provide access to as many of these
resources as possible from a single place. That is why, for better or
worse, since we have adopted plone I advocate that we keep trying to
remain within that environment.

Shane.

>>
> Hi Andre,
>
> This is one of a list of services that I also would like to have. I have
> discussed this with Randall recently and I believe he intends to follow
> them up one-by-one with IT:
>
> 1) Bug tracker (status: in progress with IT, interim solution available
> on my system)

no comment

> 2) Web interface to VC such as Trac Subversion viewer (status: Randall
> to bring up with IT, interim solution available on Matt's server)

There are several plone based viewers. That seems desirable for the
reasons of a single place to go and single search.

> 3) Code cross-reference / browser such as LXR (status: Randall to bring
> up with IT, no interim solution yet)

Would be great. Have desired this for cmgui for a long time.

> 4) Functional test management such as Litmus (status: Randall to bring
> up with IT, interim solution available on my system)

We currently use the cmiss examples system for cm, cmgui and the old
OpenCMISS.

It features

1. cross platform support (linux, aix, osx, irix and could do win32 if
we could mount it).
2. home grown perl scripts (harder to support)
3. load limitation. Each night it runs on a machine for a fixed length
of time covering off jobs in some priority based on i. how fast they
last ran, ii. how long since they last ran, iii. whether they passed or
failed. This is important as valgrind cmgui testing and cm testing in
general takes many hours, more than can be done each night.
4. image comparison, comparisons of numbers with numerical tolerances
against answers.
5. individual subscription (although this requires putting your email
into the example control files).
6. single email for all projects. A user who is testing cm and cmgui
and some individual examples from another project gets a single email on
the tests and the compilations they care about and no more.
7. extensible. The framework is available to any program by writing a
short script to run the various desired ways.
8. supports running multiple executables in multiple configurations,
such as rerun with valgrind,
9. web page for each example with history of all its runs on all platforms
10. gz file package for each example.
11. can run subsets of examples and versions based on regular expressions
12. notification of recently broken examples first, with cvs log
messages that match those broken examples listed in email

> 5) Crash reporting system to receive reports over HTTPS from clients,
> and provide developer access to them, such as Google Breakpad (status:
> Randall to bring up with IT, no interim solution yet. Not enabled in any
> PCEnv releases but support available in Mozilla)

Sounds a good idea. We don't have a solution for this for cm or cmgui
or openCMISS yet.

> 6) Automated update system allowing updates to be deployed over HTTPS.
> This can be done with just a static-serving HTTPS webserver that we have
> access to push updates on to (status: Randall to bring up with IT, no
> interim solution yet. Not enabled in any PCEnv releases but support
> available in Mozilla).

Also a reasonable idea. We are trying to use addons.mozilla.org for zinc.
We don't have a solution for cm or cmgui or openCMISS at the moment.

> 7) Proposal management. This may just consist of a policy of how to use
> our existing resources better, and may involve an update to the existing
> Plone software centre.

That would be good. Seems like it should integrate well with the tracker?

> Best regards,
> Andrew
>

You also don't mention an automated build system....
That seems important too.
cm, cmgui, zinc and unemap use cmissmake and cross compiler environments
for platform independence. There was some discussion a couple of weeks
back about some virtual machine build servers.






Archive powered by MHonArc 2.6.18.

Top of page