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

On 7/5/2010 8:20 AM, Paul Moore wrote:

On 5 July 2010 11:11, M.-A. Lemburg 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