discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code review [Was: GNA is down...}


From: Quentin Mathé
Subject: Re: Code review [Was: GNA is down...}
Date: Tue, 14 Feb 2012 15:51:51 +0100

Le 14 févr. 2012 à 12:49, David Chisnall a écrit :

> On 14 Feb 2012, at 08:43, Sebastian Reitenbach wrote:
> 
>> Code review is usually done before its commited to the main tree. For each 
>> part of the tree, there is at least one, sometimes more maintainers.
>> If you have changes, you figure out, who is the maintainer, and send the 
>> patch for review.
> 
> There are better tools for this.  For a while for Étoilé Nicolas ran 
> ReviewBoard[1], which let you upload a diff and let other people inspect it 
> against the current svn head.  LLVM has a mechanism that works the other way 
> and scrapes the llvm-commits mailing list for patches as attachments and 
> presents them in a web interface (I'm not sure what this uses, but I could 
> find out).
> 
> For post-commit reviews, pretty much anything supports showing the diff in a 
> convenient way.  I usually look at GNUstep changes using viewvc on GNA, which 
> lets you inspect a revision, see what has changed, and inspect diffs for 
> everything.  Fossil has a similar functionality built in (and, because the 
> web UI can run locally, you can see the same interface whether connected or 
> disconnected).   Github has a version that reflects the git philosophy: more 
> features, worse UI.

I'm not sure what gave you this impression about the code review support in 
GitHub. The Pull Requests section for code review looks easy to use but more 
limited than ReviewBoard though. 
ReviewBoard was more powerful (e.g. precise comparisons between patch 
revisions, review per patch revision, side-by-side diff, threaded comments) but 
had some UI pitfalls too.

On a more general note, it looks to me that there are two difference kind of 
reviews. Reviewing patches (for major changes or from people without commit 
access) and reviewing commits. Now it is true that if you use a DVCS the line 
between the two is blurred, but it still exists imo.
For the first case, a dedicated tool like ReviewBoard is the best choice. For a 
DVCS and from a pragmatic viewpoint, an integrated solution based on Pull 
requests such as the one available on GitHub or BitBucket is the less work to 
set up and use.
For the second case the 'commit comments' feature of Github seems appealing. 
However replying to the commit mails as we do now, altough it is a bit less 
convenient, works well enough in my experience.

Cheers,
Quentin.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]