[Dune] suggestion for testing

[Andreas Dedner]

Hi,
once again I have the feeling that there has been
a huge amount of misunderstanding with respect to
this issue. I never had in mind, that every little
change to dune-grid,dune-common should be subjected
to a huge amount of testing before being committed.
My suggestion was only concerned with changes to
the build system.
Having said that much I now suggest to leave the
problem to Christian and Martin. If Christian thinks
that sending a patch to Martin is to much bother
than that his decision and otherwise Martin is
totally willing to do the suggested amount of extra
work and he will a thank you from me at least!
So why don't Christian and Marting continue this
exchange - at least if Christian thinks it is a good
idea - on their own and see if they can come to
some manageable plan?
Best
Andreas

Oliver Sander wrote:
> Hi!
> I agree with Sven in that the amtliche solution would be to have
> a special testing branch.  However I think for a project of our size
> both Sven's and Andreas's suggestions are overkill.  There is currently
> a refactoring of the build system and, yes, there have been disruptive
> patches.  But looking at the last years this has been really rare.
> I propose the following procedure:
> - no additional branches
> - get the automated build system running again [in fact, I suppose it
>  would have been smarter to have that _before_ starting to tear apart
>  the build system]
> - post a warning to the list before committing something dangerous.
>  In the long run I do not expect this to happen very often.
> - If svn-head is broken: do not get mad.  It is a development branch
>  after all.  If you need some stability do not update after a warning
>  has been issued.  If you needs lots of stability use a release branch.
> 
> -- 
> Oliver
> 
> Sven Marnach schrieb:
>> Hi Andreas,
>>
>> Andreas Dedner schrieb am Mo, 19. Mai 2008, um 15:51:40 +0200:
>>  
>>>> Managing patches is actually the job of a version control system.  The
>>>> usual way of dealing with this problem is to have a testing branch
>>>> where all dubious patches go, people or test suites test this branch,
>>>> and patches that are found to be working fine are merged back to the
>>>> trunk.
>>>>       
>>> I agree, but do you have a suggestion of how
>>> this can be done without too much fuss?
>>> Would this require a development branch in which
>>> changes are committed and then they are merged
>>> into the trunk after some testing. What would be
>>> a good way of doing this?
>>>     
>>
>> That's what I would suggest.  Patches go to testing first, and are
>> merged to the trunk if they pass the automatic tests.  Maybe every
>> developer should be responsible to merge her own patches to the
>> trunk.  Of course this involves to commit every patch twice, but we
>> won't be able to solve the problem without _any_ additional work.
>>
>>  
>>> Having a directory of the form
>>>   dune.org/patches/today/patch*
>>> would perhaps not be perfect but would be easy
>>> to get working right a way.
>>>     
>>
>> I see several problems with this approach.  First, it would be more
>> work to set it up than my suggestion.  You would have to adapt your
>> test scripts to find the correct patches, apply them, deal with
>> conflicts etc.  We would have to provide an upload infrastructure etc.
>> In contrast, the solution I suggested requires to create a testing
>> branch in subversion and tell the test suite to check out the testing
>> branch instead of the trunk.
>>
>> Second, you wouldn't have any help in merging.  Patches can (and will)
>> conflict to each other and can conflict to commits that are posted
>> after the patch was uploaded.  If some hunk in a patch conflicts with
>> a later commit, the patch won't apply.  You have to deal with all
>> conflicting hunks manually.  Subversion would perform a three way
>> merge and deal with conflicts in the usual way, i.e. writing all three
>> version in files an generate a partially merged file with conflict
>> markers.  Of course, you could create an infrastructure that keeps
>> track of the respective version each patch applies to and write
>> scripts to try a three way merge, but that surely would be a lot of
>> work to get a functionality svn provides out of the box.  Subversion
>> doesn't help you in merging as much as better RCS's, but it is surely
>> more convenient than doing everything manually.
>>
>> I think your suggestion would produce _lots_ of work, much more than
>> the way I suggested.  But I have another suggestion that is even less
>> work.  The automatic test suite could be modified to create a
>> subversion tag pointing to the latest version that passes the test
>> suite, and update this tag every time the test suite passes.  So if
>> someone just needs a working version, she would know where to look for
>> the latest working version.
>>
>> Greetings from Stuttgart,
>>     Sven
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>>   
> 
>