getting ready for the sprint - code review with hg

[Gilles Moris]

For code reviews, I am using ReviewBoard and the mercurial-reviewboard 
extension to access it:
http://www.reviewboard.org/
http://code.google.com/p/mercurial-reviewboard/

It has mostly everything that I need:
- public access
- review groups and mail notifications
- possibility to track diffs between each submissions

What is still missing is:
- SSH access to the repo
- formal acceptance policies for the patch

But there are plan for that supports.

Regards.
Gilles.

On Wednesday 03 February 2010 06:22:27 pm Nicolas Chauvat wrote:
> Dear List,
>
> I am trying to do my homework before the
> http://mercurial.selenic.com/wiki/1.5sprint
>
> I have not contributed to hg before, but I just read
> http://mercurial.selenic.com/wiki/DeveloperInfo and
> http://hgbook.red-bean.com/read/
>
> I have also read about the possible agenda on the sprint page and
> could be interested in working on the following items:
> - Improving the development process
> - Usability
> - Use of ui.progress()
>
> But the most interesting for me would be to work on facilitating
> reviewing code with mercurial.
>
> We currently do it with mq, but I have a strong feeling this could be
> improved to become a lot more easier than it is now.
>
> Contributors do not have write access to the project repository, but
> have write access to the mq repository. Contributors work on their
> patches in their own branch, then commit and push their patches.
>
> When notified by contributors that patches are ready, reviewers pull
> everything from the mq repository in one go, then jump to the right
> branch and review the patches. If the patches are good, applying them
> is easy. If the patches are not good, things get more complicated than
> we would like them to be.
>
> * where to put comments about patches ? we have tried logging the
>   discussion about patches in a README file put in the mq repository,
>   but that's not always as practical as it may sound at first.
>
> * asking contributors to merge or split their patches is often the
>   right thing to do from a reviewer's point of view, but is a bit of
>   work from the contributor's point of view, especially splitting
>   patches.
>
> * making the whole review process public and beneficial to other
>   contributors that are preparing patches is not trivial.
>
> * having an archive of the reviews easily usable for further reference
>   is not trivial either.
>
> I am aware of
>
> * http://mercurial.selenic.com/wiki/PatchBranchExtension
>
> * http://arrenbrecht.ch/mercurial/pbranch/
>
> * http://bitbucket.org/alu/hgtasks/wiki/Home
>
> Is there any consensus about what the best option would be ? Is anyone
> else interested in focusing on this topic during the sprint ? Is there
> anything else I could read to be ready for the sprint ? Any thoughts,
> even random ?