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

[Thomas Jollans]

On 07/05/2010 09:30 AM, M.-A. Lemburg wrote:
> Thomas Jollans wrote:
>> On 07/04/2010 03:53 PM, Tarek Ziadé wrote:
>>>
>>> Do you have an easy way to perform this cleanup ? Could you propose a
>>> process here ?
>>>
>>> I am bit skeptical that contributors will do this, whereas a patch
>>> policy makes sure we don't have to deal with this, and avoid asking
>>> people to have a high mercurial-fu. I am also skeptical that
>>> contributors are willing to digg into a clone to get what they want
>>> and/or check that it's fine to pull.
>>>
>>> It seems to me that patches are the universal format to propose a
>>> change and are easy to produce and consume. Contributors can use any
>>> process they want to create it, even without using mercurial.
>>
>> There's no reason to force those of us capable of producing clean hg
>> branches back into the world of patches. I can see why you'd want to be
>> able to say "no, this repo is a mess. Submit something presentable, like
>> a patch." Some "how to contribute" document might recommend using mq,
>> but it shouldn't be a requirement - pulling comes naturally with DVCS.
>> Python should use it.
>>
>> Accept patches - sure - not everyone uses mercurial. Require patches -
>> please don't!
> 
> I'm with Tarek here: the only way for core developers to be able to
> review checkins on the checkins list is by looking at the patches
> that go in.
> 
> Having to look at 10+ checkin emails for a single "patch" will
> break this review process - no-one will be able to follow what
> a particular pulled set of changes will do in the end, compared
> to what we had in the repo before the pull. As a result, the
> review process will no longer be possible.

If the problem is the amount of changesets per "patch", then it has to
be the responsibility of the person committing - be that a core dev or
an external contributor - to make sure it's only a single changeset.
OTOH, I don't think being that strict about it is a good idea - in many
cases, having a handful of changesets is, IMHO, better, with Mercurial.

Either way, if there is some sort of policy stating how changes should
look, I for one would be happy to publish a branch on bitbucket or my
own hgweb instance in that format. Permitting text patches is a must,
but requiring text patches when we have actual distributed branching is
quite the anachronism.

> 
> As example, see Tarek's pull/push of the distutils2 work. Those
> checkin email will just rush by and not get a second or third
> review.

If the problem is the amount of emails per "patch" then, for god's sake,
change the script that writes the emails to send a mail per push,
instead of a mail per commit !

DVCSs allow one to have small, atomic (but, of course, inter-dependent)
commits, and push them later. I myself feel that this property should be
valued, not feared.

> OTOH, I don't think that requiring to open a ticket on the tracker
> for everything is needed either.
> 
> Aside 1: Isn't it interesting that the more we actually think about
> moving to Mercurial, the more we find that the existing Subversion
> model of working is actually a very workable model for a large
> open source project ?!

It's all a question of how changes are reviewed and synchronised. Of
course, the Python subversion model works, no question. The specific
approach "turn every commit into an email for proof reading" appears to
work well with it. It may not work as well with hg. It may work better
if you s/commit/push/ instead of s/commit/changeset/. Other projects
work in a more distributed fashion, with developers' private
repositories, changes being reviewed before pulling/merging. Linux is,
of course, a prominent example. If this approach is for Python, I don't
know. I doubt it, at least for the time being. But a suitable workflow
will surely be found.


Ah well, we'll see what happens.

Thomas