[Python-ideas] Using only patches for pulling changes in hg.python.org

Terry Reedy tjreedy at udel.edu
Mon Jul 5 21:20:41 CEST 2010

On 7/5/2010 8:20 AM, Paul Moore wrote:
> On 5 July 2010 11:11, M.-A. Lemburg<mal at egenix.com>  wrote:
>> The point I wanted to make was that (at least some of) the core
>> devs do monitor the checkins list for new code and/or changes
>> to existing code going in. This would not longer reasonably
>> work, if you start pushing revisions of patches down the list
>> as well.
> I agree entirely that commits should be made up of "completed"
> patches, not of "work in progress" (patch 2 fixing a badly named
> variable in patch 1, etc).
> But there may be merit in breaking a large patch into a series of
> self-contained, incremental changes - which *can* be reviewed
> independently, but which make sense as a group. For example, one patch
> that introduces set literals, a second which updates the standard
> library code to use them.

Devs have occasionally asked a submitter of a large patch to split it 
into reviewable pieces. But that should be a special-case decision of a 
commiter reviewer.

> As a more radical possibility, a patch could
> be broken up into 3, one with the code changes, one with the tests and
> one with the documentation. That may be less acceptable, although it
> does allow for the possibility of someone with little C experience to
> contribute by reviewing the docs and tests without having to worry
> about the code.

I do not see that as being so useful. Patches have section for each file 
and I have no trouble not reading a file section. Part of review is 
checking that doc and code changes match. Also, test and code patch have 
to be applied together.

Terry Jan Reedy

More information about the Python-ideas mailing list