getting ready for the sprint - code review with hg

Steve Losh steve at stevelosh.com
Wed Feb 3 11:33:36 CST 2010


Oops, I hit send before including the link.

My hg-review extension is getting close to usable, though I haven't  
tackled MQ patches yet. The project is at http://bitbucket.org/sjl/hg-review 
  -- I still need to write nice documentation for it but there a a  
bunch of pages on the project wiki explaining how it works.

On Feb 3, 2010, at 12:22 PM, Nicolas Chauvat  
<nicolas.chauvat at logilab.fr> 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 ?
>
> -- 
> Nicolas Chauvat
>
> logilab.fr - services en informatique scientifique et gestion de  
> connaissances
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list