- From: ak.miller at auckland.ac.nz (Andrew Miller)
- Subject: [cellml-discussion] physiome project developer infrastructure
- Date: Tue, 02 Oct 2007 16:03:15 +1300
Shane Blackett wrote:
>
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.
>
Please see my comments regarding this further down.
>
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.
>
The problem is that many of the Plone products available are no where
near as good as some of the non-Plone options in terms of features,
usability, and so on.
>
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.
>
Although I have yet to see a Plone-based system which I particularly like.
>
>
> 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
>
I think this more similar to our unit test system as opposed to the
functional test system. We already have a home-grown system for this for
the CellML tools as well (although this is a separate infrastructure
issue as there is an effort to move this over on to a shared system and
have continuous builds / testing as opposed to hourly builds, which
Randall is co-ordinating).
The functional testing system is intended primarily for user-supervised
tests, and are essentially recipes for what the user must to do in order
to test all the functionality of the application.
>
>
> 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?
>
I think that it could involve the tracker, although there are several
different ideas on this going around.
Best regards,
Andrew
>
>
> 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.
>
>
>
_______________________________________________
>
cellml-discussion mailing list
>
cellml-discussion at cellml.org
>
http://www.cellml.org/mailman/listinfo/cellml-discussion
>
Archive powered by MHonArc 2.6.18.