Re: [AMBER-Developers] Testing Server

From: Scott Brozell <>
Date: Sat, 16 Oct 2010 14:54:32 -0400


On Sat, Oct 16, 2010 at 03:32:20PM +0000, B. Lachele Foley wrote:
> The problem: We know that before we submit a bug, we should install and compile the latest version in a stable environment, etc., and test there. But, Amber is large and everyone is always stressed, particularly so after fighting weird resutls for an hour or two only to find it really wasn't your input file. So, we don't necessarily report every bug because we simply might not have time in the moment to do the proper testing to make a good report. In our group, we often get around bugs by keeping old versions of Amber and just switching to one that works for whatever it is we want to do. Right now, we have a possible bug in ptraj with files over 4 GB, but as you might imagine, the testing alone for a 4 GB file is very time consuming, and not a priority for a grad student who can just switch to a different Amber and get the job done.

Part of the fame and glory of being an Amber developer is testing
the current code base via real research simulations. Bypassing the
testing/reporting/fixing responsibility by using old versions
is bad for Amber - for the many reasons, see old am-dev posts or e-me.

Based on bugzilla, Id say that your group reports a lot of bugs
and your reports are very good. It may be that other groups are not
reporting as many because they have the expertise to fix the bugs.
On the other hand some groups are black holes that even need continual
prompting just to get their own developments committed.
(Note that most bug reports and fixes stem from reflector postings.)

> A possible solution: Put a server somewhere that has the very latest, up to date Amber installed on it. Make it only available to developers, and maybe update the install daily or weekly, complete with tests. Then, we have a known-working, latest version system where we can try out a minimal system that we think shows a bug. Another advantage to this is that other developers can easily log in and check out the input, output, etc., when there is a bug. Depending on how rhizome-like the Amber code has become, it might also be useful for quickly finding issues generated by commits from different developers.

On Sat, Oct 16, 2010 at 06:00:11PM +0100, Mark Williamson wrote:
> The tool is called cruisecontrol and I have it running here:
> >

Mark's post was not crystal clear on whether his work will exactly
implement your proposal. But his work seems like it will be helpful.

As far as your last sentence, that is already partly handled by the
nightly testing; ok, nightly testing since the amber 11 release only
started as of last night. :)


> Of course, this won't fix all problems, but it might make it easier to make better tests and reports.
> This is something else that can be discussed at the meeting, I guess, if there is interest.

AMBER-Developers mailing list
Received on Sat Oct 16 2010 - 12:00:03 PDT
Custom Search