getting ready for the sprint - code review with hg

[Nicolas Chauvat]

On Wed, Feb 03, 2010 at 06:26:45PM -0500, Steve Losh wrote:
> Tell me what workflow you'd like to use for reviewing MQ patches. I  
> don't use them enough to really have a handle on what people need.

There is a ticket in the tracker.

A developer is tasked with the implementation of that ticket. He
produces a set of (mq) patches that he submits to review.

The reviewer comments on that set of patches and may ask the
contributor to modify it: do things differently, merge two patches of
the set since they are about the same change, split a patch since it
is about more than one change, etc.

The developer reworks his patches and submits them again to the
reviewer.

This iterative process stops when the reviewer accepts the set of
patches and commits them to the repository. The developers have read
access to the repository, but not write access.

> Would people need to review "iterations" of patches?

yes, patches have to be worked on until the reviewer can accept them.

> Say I craft a patch and you review it and say X and Y need to be  
> changed. I make those changes and want it reviewed again.
>
> Would you want to see/comment on the brand new fresh patch as a whole or 
> would you want to only see/comment on "how the patch changed" (i.e. the 
> diff of the diff)?

The patch as a whole.

> How can we uniquely identify a patch across "iterations"? Is the  
> filename good enough?

Filename is good enough.

> We should chat about it at the sprint for a few minutes at least. I  
> think having a useful, offline-capable code review tool for Mercurial  
> would be very nice -- I just need more input on what would actually make 
> it "useful".

Let's do that.

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances