[gmx-developers] could somebody fix the regressiontests package?

Mark Abraham mark.j.abraham at gmail.com
Wed Feb 27 14:52:04 CET 2013


On Tue, Feb 26, 2013 at 5:50 PM, Roland Schulz <roland at utk.edu> wrote:

>
>
>
> On Tue, Feb 26, 2013 at 10:25 AM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:
>
>>  Bump!
>>
>>  I have not had time to figure out a solution. Does anybody have
>> suggestions on how to fix this?
>>
> you simply upload a fixed version. I think the proper fix is that for the
> git version, git is used to download. It only makes sense to download a TGZ
> from http if the source is also a tar ball. But I was waiting for us to
> decide whether we will change regressiontests to a submodule before I
> change that.
>

I can see clear value in making regressiontests a submodule for master
branch. Roland, Szilard and I have been discussing offline how to set up a
Jenkins configuration that will make it fairly simple to do automated
testing of matching code and tests. The price will be that the code repo
must bump every time the test repo does, because it maintains a copy of the
SHA of the test repo. That's an acceptable price for having Jenkins know
immediately how to check out a matching test module via the submodule
mechanism.

Making regressiontests a submodule for for release-4-6 is not something I'm
enthusiastic about. We do have to fork the regressiontests master branch
some time very soon. I can't see people finding time to do more than
trivial maintenance on regressiontests:release-4-6 branch hereafter. So
setting up a process to tag and tarball that branch at the time we make a
4.6.x patch release, and make that release tarball download the matching
test tarball seems workable. I foresee that regressiontests tarball
changing very rarely.

People using 4.6-era git branches can either use the above tarballs or
check out the regressiontests repo in the old way. So can Jenkins, since
the frequency of test repo updates should be low.

Looking forward, some of the functionality currently in the regressiontests
repo are actually unit tests. I think the "simple" tests are each just
exercising a small number of bonded interaction functions. Likewise, the
(group) "kernel" tests only have to exercise one function under various
conditions. Everything else that they do either can or should be done by
the other tests. So in master branch I think "simple" and "kernel" should
go and be unit tests (and I've been tinkering with how best to do that).
That will cut the size of the regressiontests repo by about a factor of
two, and the execution time of those tests by a lot.


> I have a serious concern: as nobody has noticed this except me, I think
>> people are simply running the regressiontests (while I do know that many
>> people are using the source from git). I tend to think this is a problem of
>> communication/documentation and we should try to improve on this aspect.
>> Not only that if the tests are not used it was a half-futile effort to make
>> them work, but knowing how fragile intrinsic-based kernels are, it is also
>> dangerous.
>>
> According to https://code.google.com/p/gromacs/downloads/list the 4.6 was
> downloaded 328. I think this makes this useful. master was only downloaded
> 15 so it seems that my assumption that it is mostly useful to people with
> tar ball not git is mostly true.
>

Agreed. Any sign of activity with users testing our code is a good thing.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130227/a4ee990b/attachment.html>


More information about the gromacs.org_gmx-developers mailing list