tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

proposed experimental process: Suspicious Code Review 

[Imported from Trac: page PatchReviewProcess, version 26]
zooko 2013-09-20 19:53:12 +00:00
parent f3d8c585a8
commit a89e134f40
1 changed files with 4 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
PatchReviewProcess.md

@ -40,6 +40,10 @@ A few simple suggestions:
3. You don't have to be extra picky when doing patch review. The goal is just to watch out for bugs or things that would reduce the quality of the codebase. 3. You don't have to be extra picky when doing patch review. The goal is just to watch out for bugs or things that would reduce the quality of the codebase.
4. Write comments about specific parts of the code. This demonstrates that you actually read it carefully enough to understand and care about parts of it, and it makes the author feel good that someone is talking about what they wrote. 4. Write comments about specific parts of the code. This demonstrates that you actually read it carefully enough to understand and care about parts of it, and it makes the author feel good that someone is talking about what they wrote.
# Experiment: Suspicious Patch Review
Maybe it would be fun to imagine, while you're reviewing a patch, that the author has been compelled to slip a Trojan into the patch by evil adversaries, and it is your job to notice it! That's why you are motivated to request that the author rewrite or explain any confusing parts, because any parts of the patch that confuse the code-reviewer are parts where a Trojan could slip through. Of course, well-written Trojans are indistinguishable from normal old innocent bugs, so if you find a bug this way, give the author the benefit of the doubt and assume that it was an honest mistake.
## Using trac and github ## 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 further 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.)