Version 2 (modified by, 13 years ago) (diff)


At April 2010 Meeting we talked about what is good and sad about the current state of code reviews. Here's some points that showed up:

Bugzilla Advantages:

  • Strong link between review and bugs and commit queue - integration
  • Comments are emailed out automatically
  • Full pretty printed diff
  • Patch history
  • Web based
  • Intra-line diff hightlight
  • Command line access to initiate review
  • Very low downtime
  • Low incompatiblilities
  • Fast
  • Multiple unrelated patches in a single bug

Bugzilla Caveats:

  • Inefficient line by line review
  • Diff between "patches revision" inside a bug
  • General unrefinement of bugzilla
  • No draft saving
  • No statistics about the patch properties on the bug report page (number of lines, new layout tests, etc)
  • Navigate the patch at the file level
  • Lack of context for each diff chunk
  • More granularity in "review result", to improve the clarity of the communication, like "r+ but with small changes"
  • Unclear accronyms (what does r+ means?), ramping up. Use more English words (?)
  • Review progress, especially in the case of multiple reviewers (who review which parts)
  • Lack of key bindings
  • Review on a cell phone / tablet (at least basic tasks)
  • It would be nice if there was only one account - DO NOT add a third account
  • Email based review
  • Syntax based highlighting

Don't care:

  • Review on top of review, on top of patch
  • Full commandline access
  • Single patch affecting multiple bugs

Requirements for replacement:

  • Keep similar process, integration in bugzilla

Action Items:

  • Prototype, prefer a dual-review system during transition, if a transition ever occurs.
  • Any prototype should update back bugzilla to stay in sync.
  • Fixes to bugzilla work flow are welcome