[webkit-dev] to reitveld or not to reitveld

[Joe Mason]

Mark Rowe wrote:
> - UI is intimidating to newcomers.  This is clearly subjective, but 
> since the goal here is to make the review process friendlier, 
> especially for new contributors, I think it deserves calling out.
FWIW, after playing around with it for a few minutes I find its UI much, 
much friendlier than Bugzilla's itself.

However, add me to the list for "not unless we can get seamless 
integration with the bug tracker and source control".  I think the 
biggest confusion for newcomers would be keeping track of the difference 
between the three tools, not learning how to use each one.  It doesn't 
matter to me whether this is achieved by actual deep integration with 
Bugzilla, or just passing data back and forth, as long as it feels like 
deep integration to the user.

As a wild speculation: how hard would it be to build a new bug tracker 
by adding fields to Rietveld's issue descriptions, rather than trying to 
make changes to Bugzilla?  (A new bug report would simply be an issue 
without any patches uploaded yet.  We would need a space for general 
comments not tied to a line of code.  We'd need more metadata about each 
issue (component, priority, etc) and probably some new search and 
summary screens.  What else would be needed?)

Add a CON for Rietveld: there's a surprising amount of overlap between 
computer terminology and the Rietveld method of crystallography, making 
it hard to sort out google results when looking for reviews of it.  Does 
anybody know of any unbiased third-party user stories that might help us 
evaluate the tool?

Ojan or others who know the tool - can you explain a bit more about how 
it integrates with svn?  I was under the impression that you just attach 
a patch, which could be from any source, but browsing 
http://code.google.com/p/rietveld/issues/list shows a few bug reports 
about svn integration that make it seem Rietveld is pulling more data 
from it (for instance, issue 82: ignores files created by svn cp, issue 
100: fix for upload.py and svn with externals, and of course the 
eloquent issue 117: support cvs).  Would git integration mainly be a 
matter of making sure it parses git's patch output correctly?
> Subjective, less important issues:
> - I'm not sure about keeping patches and the bugs that they address in 
> separate systems.  It seems that discussion about a bug can end up 
> split between the two systems.
I don't think that's a minor issue at all.
> - It's hard to spell.  Retyping it to fix the spelling makes me sad.
Agreed.  I expect will all end up calling it rfield soon enough (and I 
even typed that as rfiled the first time).
> Ojan also mentioned ReviewBoard in his original email.  I've used it 
> only briefly, but I do know that it addresses some, but not all, of 
> the issues above (It's not tied to AppEngine, it works with both 
> Subversion and Git, and has some support for external authentication 
> mechanisms).  It may address others, but I've not looked closely 
> enough to know for sure.
I'd like to hear some more comments on other code review systems.  Does 
anyone have any more in-depth comparisons with rfield?  Do they all use 
basically the same methodology with slightly different UI's, or are 
there major differences in approach?

Joe