db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Newcomer observation: contribution/commit testing takes too long!?
Date Mon, 18 Jun 2007 18:12:16 GMT
Also note that there is no rule that one must run all the tests
before submitting a patch/committing.  For non-committers it
makes it much easier for committers to feel safe looking at your
patch.  But for instance a test only change need not run all the
tests or a change to client only code could choose not to run
non-network server tests.

As a committer I tend to run all the tests most of the time, it
just is easier to let the machine verify a patch and causes less
trouble for the community - I wish it only took 2 hours on my
machine :-).  If you do choose to commit without
running all tests, please makes sure you are able to check the
public results being posted.  For instance keep a close eye on
the next tinderbox run and make sure to step up and let people
know if you think a new error may have been caused by your checkin.
A new error in the test suite can cause a large number of people
extra work trying to figure out if it is their issue or not.

I believe the rule is to run what you feel necessary to test the
change you are submitting.  Of course for new contributers that
is hard to have a feel for, so all the tests is always safest.

Kathey Marsden wrote:
> Thomas Nielsen wrote:
>> IMHO the tests you need to run before submitting a patch, that is 
>> suites.All and derbyall, take too long to run. On my reasonably new 
>> box* it takes in excess of 2 hrs to run them both.
> There are a couple relevant issues filed:
> https://issues.apache.org/jira/browse/DERBY-1116
> Define a minimal acceptance test suite for checkins
> https://issues.apache.org/jira/browse/DERBY-2638
> Create an option for junit tests to run only client tests

View raw message