> Bypassing the testing/reporting/fixing responsibility by using old versions is bad for Amber - for the many reasons,
We dig this, we agree, and we do try. We have Amber Sprawl on all the main computers in our lab. Granted our last development build is a month old, but I've been trying to finish a paper... Grad students need to get research done so they can publish papers and graduate. I can't blame them for focusing on that. They get plenty of frustration out here on the bleeding edge. They're willing to help. It's just that their time is generally oversubscribed as it is.
The reason we suggest the testing server is to help us determine what is actually a bug and what is something else (bad libraries, whacked input files). Cloning, building, testing and then testing for the bug can take hours, particularly when you get into "does it happen on Intel? 32-bit? did it happen in amber10? different compiler? etc., etc..." It can get even more complex, for example, when installation rules change during development. If there were a platform where we could get a quick assessment of whether it works in an "approved" configuration, our troubleshooting would be eased significantly.
:-)
________________________________________
From: Scott Brozell [sbrozell.rci.rutgers.edu]
Sent: Saturday, October 16, 2010 2:54 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] Testing Server
Hi,
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:
> > http://git.ambermd.org:8080/dashboard/tab/dashboard
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. :)
scott
> 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
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Oct 16 2010 - 13:30:02 PDT
