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

[Terry Reedy]

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