Changes between Version 22 and Version 23 of PatchReviewProcess


Ignore:
Timestamp:
2013-08-08T12:55:25Z (8 years ago)
Author:
daira
Comment:

More about testing

Legend:

Unmodified
Added
Removed
Modified
  • PatchReviewProcess

    v22 v23  
    4343== Using trac and github ==
    4444
    45 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.)
     45The 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.)
    4646
    47 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.
     47In 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.