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

M.-A. Lemburg mal at egenix.com
Mon Jul 5 12:11:06 CEST 2010

Thomas Jollans wrote:

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.

You need those patches anyway, since that's how we review things on the issue tracker.

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.

The history of those patches is not all that interesting to Python developers. It's the final outcome, that makes the difference.

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.

This is not a matter of receiving the patch in 10+ emails, or lumping everything into one email.

I simply don't see any benefit in having to follow the path of development of a patch. Much to the contrary: it only adds noise that distracts from the important bits. The discussion of a patch is recorded on the issue tracker anyway and in a form that is more easily comprehensible than a set of checkin messages.

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.

Certainly.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Jul 05 2010)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2010-07-19: EuroPython 2010, Birmingham, UK 13 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

More information about the Python-ideas mailing list