[webkit-dev] to reitveld or not to reitveld
jam at google.com
Wed Jun 10 14:30:54 PDT 2009
On Wed, Jun 10, 2009 at 8:12 AM, Joe Mason <joe.mason at torchmobile.com>wrote:
> 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?
We use a script with Rietveld, gcl.py, that handles changelists. It allows
you to have multiple changes on the same repository, each identified by a
name. The script automates creation of a Rietveld issue when you first
upload. It handles things like copied/moved/deleted/image files.
> 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?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev