On Wed, Jun 10, 2009 at 8:12 AM, Joe Mason <joe.ma...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
