harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: svn commit: r477149 - in /harmony/enhanced/drlvm/trunk/build/make: targets/kernel.test.xml test.properties
Date Tue, 21 Nov 2006 04:14:13 GMT

Alexei Fedotov wrote:
> Hello,
> If a developer runs all tests in one VM and they pass, that's great
> and he can commit. Can developer make a commit if tests pass in
> "perTest" mode and fail in "once" mode?
> Let's imagine following scenarios of cooperative development when
> pre-commit test suite demonstrates unpredictable behavior (such as
> "once" mode").
> Scenario A.
> 1. A developer runs tests one time, and tests failed.
> 2. He runs them again and tests passes.
> 3. He commit changes.
> Why do we need to exercise developers' patience? Simple tests are
> predictable - they either pass or fail.

Well, no.  If we've achieved stability, and are really being truthful 
about "no regression", that committer shouldn't commit that.  "Being 
lucky" isn't a reason to commit changes.

> Scenario B.
> 1. Developer A pass tests and commit his changes.
> 2. Developer B checks out a fresh workspace, makes changes and runs
> tests - they failed.
> 3. He digs out the problem to the stage when he runs tests for the
> clean workspace - tests fail since he has slightly different
> configuration.
> Developer B suspects developer A to run tests multiple times, or skip
> acceptance test run at all. This destroys mutual trust. This makes me
> think that the simpler pre-commit tests are, the better.

I don't understand what simplifying the tests achieve.  If developer B 
has a problem, he or she should ask developer A about it.

> Thanks!

View raw message