- <p>We prefer for this to be handled before submission but understand that it's
- not possible to test all of this for every submission. Our nightly testing
- infrastructure normally finds these problems. A good rule of thumb is to
- check the nightly testers for regressions the day after your change.</p>
-
- <p>Commits that violate these quality standards (e.g. are very broken) may
- be reverted. This is necessary when the change blocks other developers from
- making progress. The developer is welcome to re-commit the change after
- the problem has been fixed.</p>
+<p>Note that llvm/test and clang/test are designed for regression and small
+ feature tests only. More extensive test cases (e.g., entire applications,
+ benchmarks, etc)
+ should be added to the <tt>llvm-test</tt> test suite. The llvm-test suite is
+ for coverage (correctness, performance, etc) testing, not feature or
+ regression testing.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h3><a name="quality">Quality</a></h3>
+<div>
+<p>The minimum quality standards that any change must satisfy before being
+ committed to the main development branch are:</p>
+
+<ol>
+ <li>Code must adhere to the <a href="CodingStandards.html">LLVM Coding
+ Standards</a>.</li>
+
+ <li>Code must compile cleanly (no errors, no warnings) on at least one
+ platform.</li>
+
+ <li>Bug fixes and new features should <a href="#testcases">include a
+ testcase</a> so we know if the fix/feature ever regresses in the
+ future.</li>
+
+ <li>Code must pass the <tt>llvm/test</tt> test suite.</li>
+
+ <li>The code must not cause regressions on a reasonable subset of llvm-test,
+ where "reasonable" depends on the contributor's judgement and the scope of
+ the change (more invasive changes require more testing). A reasonable
+ subset might be something like
+ "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li>
+</ol>
+
+<p>Additionally, the committer is responsible for addressing any problems found
+ in the future that the change is responsible for. For example:</p>
+
+<ul>
+ <li>The code should compile cleanly on all supported platforms.</li>
+
+ <li>The changes should not cause any correctness regressions in the
+ <tt>llvm-test</tt> suite and must not cause any major performance
+ regressions.</li>
+
+ <li>The change set should not cause performance or correctness regressions for
+ the LLVM tools.</li>
+
+ <li>The changes should not cause performance or correctness regressions in
+ code compiled by LLVM on all applicable targets.</li>
+
+ <li>You are expected to address any <a href="http://llvm.org/bugs/">bugzilla
+ bugs</a> that result from your change.</li>
+</ul>
+
+<p>We prefer for this to be handled before submission but understand that it
+ isn't possible to test all of this for every submission. Our build bots and
+ nightly testing infrastructure normally finds these problems. A good rule of
+ thumb is to check the nightly testers for regressions the day after your
+ change. Build bots will directly email you if a group of commits that
+ included yours caused a failure. You are expected to check the build bot
+ messages to see if they are your fault and, if so, fix the breakage.</p>
+
+<p>Commits that violate these quality standards (e.g. are very broken) may be
+ reverted. This is necessary when the change blocks other developers from
+ making progress. The developer is welcome to re-commit the change after the
+ problem has been fixed.</p>