Changes between Version 22 and Version 23 of PatchReviewProcess

Timestamp:

2013-08-08T12:55:25Z (11 years ago)

Author:

daira

Comment:

More about testing

PatchReviewProcess

@@ -43 +43 @@
 == Using trac and github ==
 
-The patch you're reviewing might be given either as an attachment, or as a github pull request. If it's the latter, then it's encouraged to use line comments on github for detailed comments or questions on the code. However, you should also write a short summary of the review on the trac ticket. (Sometimes this can be as simple as "+1" if there are no issues to discuss.)
+The patch you're reviewing might be given either as an attachment, or as a github pull request. If it's the latter, then it's encouraged to use line comments on github for detailed comments or questions on the code. However, you should also write a short summary of the review on the trac ticket. (Sometimes this can be as simple as "+1" if there are no further issues to discuss.)
 
-In all cases it's recommended to apply the patch or check out the code and run the full test suite locally (using `python setup.py test` since a rebuild is usually necessary), to check that it passes. All committed code should also be free of pyflakes errors or warnings.
+In all cases it's recommended to apply the patch or check out the code and run the full test suite locally (using `python setup.py test` since a rebuild is usually necessary), to check that it passes. You'd be surprised how often a patch author thinks it passes tests, but a "harmless" last-minute change, portability problem, or nondeterministic race condition causes it to fail when checked. (There's usually noneed to test on multiple platforms at this stage though -- that's whatthe buildbots are for.) All committed code should also be free of pyflakes errors or warnings.