Changes between Version 2 and Version 3 of ReviewTool


Ignore:
Timestamp:
Apr 12, 2010 3:10:38 PM (10 years ago)
Author:
maruel@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReviewTool

    v2 v3  
    11At [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:
    22
    3 Bugzilla Advantages:
     3== Bugzilla Advantages ==
     4Things people don't want to lose.
    45 - Strong link between review and bugs and commit queue - integration
    56 - Comments are emailed out automatically
     
    1415 - Multiple unrelated patches in a single bug
    1516
    16 Bugzilla Caveats:
     17== Bugzilla Caveats ==
     18If 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.
    1719 - Inefficient line by line review
    1820 - Diff between "patches revision" inside a bug
     
    3133 - Syntax based highlighting
    3234
    33 Don't care:
     35== Don't care ==
     36Didn't seem to have interest in the room.
    3437 - Review on top of review, on top of patch
    3538 - Full commandline access
    3639 - Single patch affecting multiple bugs
    3740
    38 Requirements for replacement:
     41== Requirements for replacement ==
    3942 - Keep similar process, integration in bugzilla
    4043
    41 Action Items:
     44== Action Items ==
    4245 - Prototype, prefer a dual-review system during transition, if a transition ever occurs.
    4346 - Any prototype should update back bugzilla to stay in sync.
    4447 - Fixes to bugzilla work flow are welcome
    4548
    46 Alternatives:
     49== Alternatives ==
    4750 - Just incrementally fix caveats in bugzilla. Here's an example to start off: http://blog.fishsoup.net/2009/09/23/splinter-patch-review.
    4851 - [http://code.google.com/p/rietveld Rietveld]. Nice, as some issues and requires significant integration effort.