lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "HowToContribute" by ErickErickson
Date Mon, 17 Sep 2012 14:21:47 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "HowToContribute" page has been changed by ErickErickson:
http://wiki.apache.org/solr/HowToContribute?action=diff&rev1=78&rev2=79

Comment:
Added section about frequently failing tests, prompted by SOLR-3846

  }}}
  Where "TestXXX" is the name of the particular Junit test you want to run.
  
+ ==== Frequently failing Tests ====
+ There are some tests that fail sometimes on some systems, but run on Jenkins fine. It's
''always'' a good idea to be sure you can run "ant test" successfully ''before'' you start
making code changes. Or keep an un-changed version of the code around to see if your changes
are really to blame.
+ 
+ One of the great things about Open Source is so many people run the tests on so many different
systems. Occasionally you'll be the lucky person who has the system that wins the prize by
having the environment that exposes a new failure mode, see the discussion at [[https://issues.apache.org/jira/browse/SOLR-3846|SOLR-3846]]
for an example.
+ 
+ If you do find one of these, here's what you should do:
+  * First, just try running 'ant -Dtests.badapples=false test'. If the tests succeed, this
is a known issue that we haven't found a solution for yet, but want to gather information
about. If you have the time, ping the dev list and include your setup details. But in the
case where setting this flag causes the tests to succeed, you can assume that your code changes
didn't cause this error and go ahead.
+  * If tests continue to fail, ask on the dev list if anyone else has seen the issue. This
is the case where having the un-changed code helps. If the tests fail on both the changed
and un-changed versions, discuss on the dev list whether the test can be annotated as a 'badapples'
test or not.
+  * If tests fail with your changes but not on un-altered code, well, you need to understand
why. By far the most frequent reason is a bug or unintended side-effect of your code, but
occasionally it's a test that needs modification. Again, the dev list is a good place to discuss
this.
+  * Be very cautious about adding anything like @Ignore to a test. This is generally the
wrong thing to do unless you get some consensus, and it'll surely generate "spirited debate".
+  * Of course any effort you want to make towards tracking down the reason a test fails in
your particular environment is greatly appreciated!
+ 
  === Creating the patch file ===
  Check to see what files you have modified with:
  

Mime
View raw message