More about testing
[Imported from Trac: page PatchReviewProcess, version 23]
parent
90b7824499
commit
b48f811642
|
@ -42,6 +42,6 @@ A few simple suggestions:
|
|||
|
||||
## 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.
|
||||
|
|
Loading…
Reference in a new issue