[webkit-dev] to reitveld or not to reitveld

[John Abd-El-Malek]

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?
>
> Joe
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090610/7d16ee06/attachment.html>