CellML Discussion List

Text archives Help


[cellml-discussion] physiome project developer infrastructure


Chronological Thread 
  • 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.

Top of page