Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110307/07b9f441/attachment-0001.html below:
<br><br><div class="gmail_quote">On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:<br>
<br>
>On Mon, 7 Mar 2011 12:04:18 -0500<br>
>Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:<br>
>><br>
>> >If we can get to a mode where non-committers can push to a "fork" on<br>
>> ><a href="http://hg.python.org" target="_blank">hg.python.org</a>, we can dodge the patch format issue by having folks post<br>
>> >"pull requests" for that fork instaed.<br>
>> ><br>
>> >For the repoze and pylons projects, we have found the quality and<br>
>> >quantity of patches went up *significantly* when we made it easy for<br>
>> >somebody who doesn't work on the code all the time to use this workflow<br>
>> >(fork to a public repo, clone, hack, commit, push, request a pull).<br>
>><br>
>> +1. Â 'Branches' are better than patches.<br>
><br>
>How do you review a branch?<br>
<br>
</div>You can merge it locally and look at the diff. Â Or use Rietveld if that's<br>
supported. Â But the reason a branch is better is because it's easier to track<br>
the submitter's changes in response to your review comments, and it's easier<br>
to make changes to their branch and push an update for *them* to see.<br>
<br>
It's easier to have a ongoing conversation about a branch than a patch.</blockquote><div><br></div><div>While I agree that *maintaining* the patch is easier in a branch, I don't agree that it's necessarily easier to review it: in Rietveld (by design!) subsequent uploads look very much like changes in a branch. The only difference with peeking directly in the branch is that it requires an explicit upload by the patch-owner, which actually has its upsides as well (no need for Rietveld to 'poll' changes, an explicit 'ok, updated according to feedback' report, no irrelevant intermediate changes to get confused at.) There's one thing Rietveld always has a bit of trouble representing, that being merges with another branch, but it's hard to imagine a clearer way to represent it without conflating the whole thing, and frankly it does a better job of it than 'hg diff' in the branch itself :-)</div>
</div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!<br>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4