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

Tarek Ziadé ziade.tarek at gmail.com
Sun Jul 4 19:09:36 CEST 2010


On Sun, Jul 4, 2010 at 6:56 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 04.07.2010 17:26, schrieb Antoine Pitrou:
>> On Sun, 04 Jul 2010 15:46:53 +0200
>> Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>>>
>>> Fourth, one-patch-per-issue is too restrictive. Small commits are useful
>>> because they're way easier to review. Concatenate several small commits
>>> leading up to a single issue fix into a single patch and it gets much
>>> harder to read.
>>
>> I don't agree with that. The commits obviously won't be independent
>> because they will be motivated by each other (or even dependent on each
>> other), therefore you have to remember what the other commits do when
>> reviewing one of them. What's more, when reading "hg log" months or
>> years later, it is hard to make sense of a single commit because you
>> don't really know what issue it was meant to contribute to fix.
>>
>> I know that's how Mercurial devs do things, but I don't really like
>> it.
>
> I think the best of both worlds is to encourage contributors to send
> more complicated patches in a series of easy-to-review steps, but when
> committing to Python, make one changeset out of them.

Exactly, so one bugfix or one feature comes in a single changeset that contains
ideally the code change + the doc change + the tests.

Like Thomas has suggested, I'll start a "how to contribute" wiki page
with the best practices,
and give the url here so everyone can contribute/correct it.

Tarek

-- 
Tarek Ziadé | http://ziade.org



More information about the Python-ideas mailing list