[Dune] suggestion for testing

[Martin Nolte]

Hi all,

the biggest problem with the automated testing of Dune seems to be that is not 
even run (at least the web site says it has last been run on Oct 15 2007. 
Moreover, I'm not sure what is actually tested. This should at least be 
documented. And last but not least, I do not see why there are objections to 
more severe tests before changing things so near to the core of Dune. It makes 
the repository more stable.

I don't know if you remember the beginning of January. There was a bug in the 
build system that was not fixed for around two weeks (and I don't want to 
blame anyone, it could have been my mistake).

The big problem with the build system is that errors there affect everybody. 
And somehow I got the impression that Christian is the only one actually 
caring for the build system (and maybe the only one understanding it). All we 
are offering is a little more help in testing...

Yours,

Martin

Oliver Sander wrote:
> Hi!
> I agree to all that has been said here, with one exception:
> we already have an infrastructure for automated testing,
> and the tests you propose should be added there.
> 
> --
> Oliver
> 
> Andreas Dedner schrieb:
>> Hi,
>> some of the recent changes to the build system
>> are quite fundamental and therefore
>> a) difficult to test
>> b) rather devastating for users not accustomed to
>>    the ''guts'' of the build system.
>> We were therefore discussing possibilities of
>> increasing the success rate of checkins through
>> testing patches on different installations of libtool,
>> g++ Version etc.
>> We have a quite complex nightly build for dune-fem
>> using tar balls from the svn head and testing with 
>> all kinds of
>> grids and similar things. It would not be very
>> difficult to add new changes to the repository, e..g,
>> the build system after checkout. This would only
>> require a patch. This can be easily done by
>> sending us a file "patchfile" generated using
>>   svn diff > patchfile
>> as an email.
>> So our suggestion would be: before a major change to the
>> build system is committed, the patch could be send to us
>> and we add it to our nightly build. The next day
>> we know if everything worked out and can either commit
>> the patch ourself our give an ok for the patch to be
>> commit. If something went wrong we can try to figure
>> out what the problem was and make a suggestion for
>> correcting the problem, which should at least then
>> work on our system and others can then try it out on
>> there installation.
>> Martin would be willing to perform this task on our side!
>> And before I forget:
>> 1) we would all like to thank Christian for the huge
>> amount of work he is investing into the build systen;
>> we appreciate how difficult it is and also how
>> difficult these change are to test throughly.
>> 2) if somebody else would also like to test a patch
>> he should just yell. All one has to do is
>> run the command
>>   patch -p0 < patchfile
>>
>> Best regards
>> the Freiburg team.
>>
>> PS: tonight we got the following message:
>> cd . && ./bin/dunecontrol --only=dune-common m4create
>> writing dependencies.m4
>>     for dune-common 1.2svn dune at dune-project.org
>> { test ! -d dune-common-1.2svn || { find dune-common-1.2svn
>> -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr
>> dune-common-1.2svn; }; }
>> test -d dune-common-1.2svn || mkdir dune-common-1.2svn
>> cp: cannot stat `./dune-common.m4': No such file or
>> directory
>>
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>>   
> 
> 

-- 
Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5642
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany