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
