[Python-Dev] We should be using a tool for code reviews

Barry Warsaw barry at python.org
Thu Sep 30 00:33:47 CEST 2010

On Sep 30, 2010, at 12:04 AM, Antoine Pitrou wrote:

>On Wed, 29 Sep 2010 17:30:10 -0400
>Barry Warsaw <barry at python.org> wrote:
>> One other thought: IME patches in general are suboptimal to
>> branches, so I think we should be encouraging people to publish
>> their branches publicly for review.  A diff is a decent way to get
>> feedback about code changes, but that's often only part of the work
>> involved in deciding whether a change should be accepted or not.  A
>> reviewer often wants to do a build with the changes, test them on
>> various tasks and application, run the test suite, etc.  For this,
>> "merge" is much better than patch(1).
>When I review a patch, I will tend to assume that the poster has
>already run the test suite (especially if it's another committer).
>Having to checkout a branch and generate a diff myself would make it
>much longer to produce a review, in most cases.

Yep, it depends on who is submitting the branch, what the branch changes,

>Even rebuilding a new branch from scratch can be slower than applying
>the diff in an existing checkout and letting `make` rebuild a couple of

You can have "co-located" branches[1] which essentially switch in-place, so if
a branch is changing some .c files, you won't have to rebuild the whole world
just to try out a patch.


[1] I only have experience with these in Bazaar so Mercurial's might work
differently or be called something different.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100929/8eb426eb/attachment.pgp>

More information about the Python-Dev mailing list