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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
