wiki:ReviewTool

Version 2 (modified by maruel@chromium.org, 14 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

Alternatives: