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

Paul Moore p.f.moore at gmail.com
Mon Jul 5 14:20:43 CEST 2010

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. 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.

Ultimately, it's for the core devs to decide, though.

Paul.

More information about the Python-ideas mailing list