On 07/03/2011 18:32, Thomas Wouters wrote:


On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <ba...@python.org <mailto:ba...@python.org>> wrote:

    On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:

    >On Mon, 7 Mar 2011 12:04:18 -0500
    >Barry Warsaw <ba...@python.org <mailto:ba...@python.org>> wrote:
    >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
    >>
    >> >If we can get to a mode where non-committers can push to a
    "fork" on
    >> >hg.python.org <http://hg.python.org>, we can dodge the patch
    format issue by having folks post
    >> >"pull requests" for that fork instaed.
    >> >
    >> >For the repoze and pylons projects, we have found the quality and
    >> >quantity of patches went up *significantly* when we made it
    easy for
    >> >somebody who doesn't work on the code all the time to use this
    workflow
    >> >(fork to a public repo, clone, hack, commit, push, request a
    pull).
    >>
    >> +1.  'Branches' are better than patches.
    >
    >How do you review a branch?

    You can merge it locally and look at the diff.  Or use Rietveld if
    that's
    supported.  But the reason a branch is better is because it's
    easier to track
    the submitter's changes in response to your review comments, and
    it's easier
    to make changes to their branch and push an update for *them* to see.

    It's easier to have a ongoing conversation about a branch than a
    patch.


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.

With the right tools reviewing branches

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 :-)

--
Thomas Wouters <tho...@python.org <mailto:tho...@python.org>>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to