Changes between Version 2 and Version 3 of ReviewTool

Timestamp:

Apr 12, 2010, 3:10:38 PM (15 years ago)

Author:

maruel@chromium.org

Comment:

--

ReviewTool

@@ -1 +1 @@
 At [https://trac.webkit.org/wiki/April%202010%20Meeting 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:
+== Bugzilla Advantages ==
+Things people don't want to lose.
  - Strong link between review and bugs and commit queue - integration
  - Comments are emailed out automatically
@@ -14 +15 @@
  - Multiple unrelated patches in a single bug
 
-Bugzilla Caveats:
+== Bugzilla Caveats ==
+If you want to fix any of these, file a bug and post patch there and update this wiki with a link to the bug so they can be removed.
  - Inefficient line by line review
  - Diff between "patches revision" inside a bug
@@ -31 +33 @@
  - Syntax based highlighting
 
-Don't care:
+== Don't care ==
+Didn't seem to have interest in the room.
  - Review on top of review, on top of patch
  - Full commandline access
  - Single patch affecting multiple bugs
 
-Requirements for replacement:
+== Requirements for replacement ==
  - Keep similar process, integration in bugzilla
 
-Action Items:
+== 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:
+== Alternatives ==
  - Just incrementally fix caveats in bugzilla. Here's an example to start off: http://blog.fishsoup.net/2009/09/23/splinter-patch-review.
  - [http://code.google.com/p/rietveld Rietveld]. Nice, as some issues and requires significant integration effort.