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@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
