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

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.


More information about the Python-ideas mailing list