[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi all,

I very much agree that well-defined and carefully implemented tests are 
extremely important and should work at all times. All help in this area is 
very much appreciated. Unfortunately, our tests do not satisfy these demands.

Therefore, I think this discussion should be kept separate from the discussion 
whether to merge a change or not.

If anyone thinks more testing should be done before the merge, I'm willing to 
support him. But:
a) I demand a well-defined test (including what external modules to use)
b) I expect the test to run on the trunk and fail on the branch
c) It should be done this week

I'm not willing to postpone the merge for another month just because people 
don't come around to testing. This entire discussion only started yesterday, 
although I announced the merge a week ago.

We can discuss everything, create a release branch before the merge, even 
postpone the merge until after the next developer meeting. But don't step 
forward just a second before the branch is actually merged (or even thereafter).

I also think that half the developers could write a mail like 'go ahead' (or 
'please wait') on such a fairly invasive patch (quote: Oli), so that the 
implementor (in this case me) knows where he stands. Such a mail is written in 
less than a minute.

Currently, my impression is as follows: Carsten and Oli would like to enhance 
the lifetime of the geometry objects, Robert agrees to merge, and some users 
are afraid of breaking their code. Of course, the positive decision on the 
last developer meeting is positive towards this change.

*NOTICE*: This is the final announcement. Unless a developer objects, the 
branch will be merged 2 PM today!

Yours,

Martin



On 02/06/2012 04:12 PM, Matthias Wohlmuth wrote:
> Hi Christoph and Martin,
> I highly agree with Christoph, that the tests are __REALLY__ important for
> such a big software framework. Most of my own codes are used by
> engineers/physicists who expect reliable results for all kind of
> configurations. The only way I can hope to provide this while introducing new
> features to the code is having many tests which immediately let know when I
> produce any side-effects.
> Therefore I disagree with Martin's earlier posts:
>>
>> With respect to your comment: I agree that in an ideal world, tests should
>> compile and run at all times. However, truth is different and I think this
>> is due to a chicken-egg problem:
> In an ideal world we would not need any tests, as we would not make any
> mistakes. However, as most of us work in the real world I think they are
> really crucial for reliable software development.
>>
>> 'make check' fails before I start my change, so it is rather pointless to
>> try 'make check' after my change. However, since my change might have
>> introduced a bug, 'make check' will not even work when other bugs are fixed.
> Yepp, that's the problem of the current situation, but this even supports that
> make check should always pass for all releases - and in my opinion also for
> the trunk. That is, first fix bugs and then add new features. (Although I
> realize that it is tempting to reverse that order ;-))
>
> And regarding that there are too many possible configurations: No one expects
> that your code works properly for all possible cases, but it is expected that
> it works for the already known test cases. Only this guarantees that a future
> release will be superior to an old one.
> In an ideal real world, you would probably even add a new test when you find a
> bug to make sure your code won't be broken again in the future.
> Besides, I really enjoy how easy it easy with the current build system to add
> new tests and to run them together. I use this a lot for my own dune-module.
>
> It's a bit of a different story, but I was really worried when I first learned
> about DUNE and saw this:
> http://autobuild.dune-project.org/buildlog
>
> Best,
> Matthias
>
>
>
> On 02/06/2012 03:07 PM, Christoph Grüninger wrote:
>> Hi Martin,
>> my comments concerning the tests in Dune were not specific to your branch. I
>> grew up with test driven development I am a huge fan of automated testing
>> and would like to see, or provide, progress in this area.
>> do not object the merge of your branch though I can not estimate its
>> effects. I like your measurements and that basic concepts can still be
>> discussed.
>>
>> Bye
>> Christoph
>>
>
>

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

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